www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Opportunities for D

reply Walter Bright <newshound2 digitalmars.com> writes:
Distilling the discussions about D that are elsewhere than this forum, some 
consistent themes emerge which we need to address to broaden the appeal of D. 
All of them require some organization and focussed effort to complete.

There's been enough jawboning about them. I figure all of them can be smartly 
blown to smithereens if we just line up 3 or 4 cannons on each.


1. Ref Counting

I believe that ARC is a pipe dream for D, as we've discussed extensively here. 
But a ref counted object should work, and would be very attractive, much like 
C++'s shared_ptr<T>.


2. Unique References

unique_ptr<T> is another big success for C++. 2.066 has already made big
strides 
in inferring uniqueness of expressions, but it doesn't go so far as creating a 
Unique!T type.


3. 'ref' means 'borrowed', to use Rust's terminology

We're almost there with this. This means better escape analysis, too.


4. Eliminating gratuitous use of GC in Phobos

This means allocations that are not transmitted back to the user. Here's an 
example of such: https://github.com/D-Programming-Language/phobos/pull/2014


5. Precise and Concurrent GC

There's been a lot of work on this, but I don't know where we stand on it.


6. Pushing decisions about storage allocation upwards out of Phobos

By having functions write to OutputRanges instead of to GC allocated buffers, 
the user can decide how to allocate the storage.


7. "D-Routines" - goroutines for D

Goroutines are the killer feature of Go for a number of sensible people. We 
pretty much have this already with fibers, but what is lacking is a scheduler, 
which will take some effort, and a "Channel" type, which should be easy.


8. NotNull!T type

For those that want a non-nullable reference type. This should be doable as a 
library type.
Jul 08 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique? In your list I'd like to add another point: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named "unapply"). Bye, bearophile
Jul 08 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 8 July 2014 at 22:21:43 UTC, bearophile wrote:
 Walter Bright:

 but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique? In your list I'd like to add another point: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named "unapply"). Bye, bearophile
What if we had an "opDestructure" or "opMatch" or something like that? It could return a tuple and be auto-implemented by the compiler for simple structs/classes. Then users could precisely control how their type can be destructured.
Jul 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Meta:

 What if we had an "opDestructure" or "opMatch" or something 
 like that? It could return a tuple and be auto-implemented by 
 the compiler for simple structs/classes. Then users could 
 precisely control how their type can be destructured.
The optional "unapply" method is from the Scala language, and it's more or less what you are suggesting, with a different name (and I agree opSomething sounds like a more fitting name for D). Such opMatch has optional arguments too, because you can match in different ways. Bye, bearophile
Jul 09 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
 (and I agree opSomething sounds like a more fitting name for D).
Added your names: https://issues.dlang.org/show_bug.cgi?id=596 Bye, bearophile
Jul 09 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2014 3:21 PM, bearophile wrote:
 Walter Bright:

 but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique?
It's not good enough.
 In your list I'd like to add another point:
 9. Built-in tuples usable in all the most important situations (with a syntax
 that doesn't kill possible future improvements of the switch statement to
 perform basic pattern matching on structs that have an optional method named
 "unapply").
The list isn't about things that would be nice to add to D, it's about fairly critical issues with large impact we need to address. More on tuples and pattern matching are not critical issues.
Jul 08 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 The list isn't about things that would be nice to add to D, 
 it's about fairly critical issues with large impact we need to 
 address. More on tuples and pattern matching are not critical 
 issues.
In this thread I have asked for just tuples, not pattern matching (I have just said that tuples design should not make it very hard to add a basic but nice form of pattern matching later in the switch statement). Regarding NotNull (your point 8), I think what's more important is to make it statically impossible for the programmer to dereference a null for a nullable type. (To do this some languages use pattern matching, that forces the programmer to handle both cases (null and not null), and in the case of not null, the programmer is handling something similar to a NotNull). Bye, bearophile
Jul 09 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 09/07/14 00:21, bearophile wrote:

 9. Built-in tuples usable in all the most important situations (with a
 syntax that doesn't kill possible future improvements of the switch
 statement to perform basic pattern matching on structs that have an
 optional method named "unapply").
I think it would be possible to implement pattern matching in library code. Something like this: match!(value, (int t) => ifInt(), (char t) => ifChar(), () => noOtherMatch() ); Destructing a type could look something like this: match(value, (type!(Foo), int a, int b) => doSomething(), // match if value is of type Foo and extract it (int a, int b) => doSomething() // match anything that can be destructed to two ints ); The syntax is not so pretty but I think it would be possible. -- /Jacob Carlborg
Jul 09 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 9 July 2014 at 07:10:09 UTC, Jacob Carlborg wrote:
 On 09/07/14 00:21, bearophile wrote:

 9. Built-in tuples usable in all the most important situations 
 (with a
 syntax that doesn't kill possible future improvements of the 
 switch
 statement to perform basic pattern matching on structs that 
 have an
 optional method named "unapply").
I think it would be possible to implement pattern matching in library code. Something like this: match!(value, (int t) => ifInt(), (char t) => ifChar(), () => noOtherMatch() ); Destructing a type could look something like this: match(value, (type!(Foo), int a, int b) => doSomething(), // match if value is of type Foo and extract it (int a, int b) => doSomething() // match anything that can be destructed to two ints ); The syntax is not so pretty but I think it would be possible.
As far as I know, there's no reason we can't add pattern matching to switch or final switch or both. There's no ambiguity because right now it's not possible to switch on structs or classes. See Kenji's DIP32 for syntax for tuples that could be leveraged.
Jul 09 2014
parent Jacob Carlborg <doob me.com> writes:
On 09/07/14 15:45, Meta wrote:

 As far as I know, there's no reason we can't add pattern matching to
 switch or final switch or both. There's no ambiguity because right now
 it's not possible to switch on structs or classes. See Kenji's DIP32 for
 syntax for tuples that could be leveraged.
There's no reason why we can add a completely new construct for this either. But it's usually easier to get a new function into Phobos then changing the language. -- /Jacob Carlborg
Jul 10 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape 
 analysis, too.
Is "scope" still left for future usage, or used for a different purpose, or deprecated? Bye, bearophile
Jul 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2014 3:37 PM, bearophile wrote:
 Walter Bright:

 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape analysis, too.
Is "scope" still left for future usage, or used for a different purpose, or deprecated?
That would have to be addressed as part of this.
Jul 08 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote:
 On 7/8/2014 3:37 PM, bearophile wrote:
Walter Bright:

3. 'ref' means 'borrowed', to use Rust's terminology

We're almost there with this. This means better escape analysis,
too.
Is "scope" still left for future usage, or used for a different purpose, or deprecated?
That would have to be addressed as part of this.
Does that mean that finally 'scope' will work as advertised? I've been waiting for that for a long time. T -- It's bad luck to be superstitious. -- YHL
Jul 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2014 10:00 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d
wrote:
 On 7/8/2014 3:37 PM, bearophile wrote:
 Walter Bright:

 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape analysis,
 too.
Is "scope" still left for future usage, or used for a different purpose, or deprecated?
That would have to be addressed as part of this.
Does that mean that finally 'scope' will work as advertised? I've been waiting for that for a long time.
Help is welcome working on a design.
Jul 09 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jul 09, 2014 at 12:47:30AM -0700, Walter Bright via Digitalmars-d wrote:
 On 7/8/2014 10:00 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote:
On 7/8/2014 3:37 PM, bearophile wrote:
[...]
Is "scope" still left for future usage, or used for a different
purpose, or deprecated?
That would have to be addressed as part of this.
Does that mean that finally 'scope' will work as advertised? I've been waiting for that for a long time.
Help is welcome working on a design.
I would, except that I'm unsure of exactly what is needed in said design. Are we just trying to nail down the exact semantics of 'scope'? Or are we looking at implementational issues (possible compiler performance hits)? Or both? Or something else altogether? Do we need to account for (what little exists of) the current implementation? Speaking of which, what *is* the current extent of the implementation of 'scope'? I assume it isn't just a no-op, since I see it applied to delegate parameters every now and then? T -- What's a "hot crossed bun"? An angry rabbit.
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote:
 I would, except that I'm unsure of exactly what is needed in said
 design.
I'm unsure as well. That's why design work is needed!
 Are we just trying to nail down the exact semantics of 'scope'?
 Or are we looking at implementational issues (possible compiler
 performance hits)? Or both? Or something else altogether? Do we need to
 account for (what little exists of) the current implementation? Speaking
 of which, what *is* the current extent of the implementation of 'scope'?
 I assume it isn't just a no-op, since I see it applied to delegate
 parameters every now and then?
Yes, yes, yes, ... these are questions that all need investigation and answering.
Jul 09 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jul 09, 2014 at 12:51:40PM -0700, Walter Bright via Digitalmars-d wrote:
 On 7/9/2014 9:08 AM, H. S. Teoh via Digitalmars-d wrote:
I would, except that I'm unsure of exactly what is needed in said
design.
I'm unsure as well. That's why design work is needed!
Are we just trying to nail down the exact semantics of 'scope'?
Or are we looking at implementational issues (possible compiler
performance hits)? Or both? Or something else altogether? Do we need to
account for (what little exists of) the current implementation? Speaking
of which, what *is* the current extent of the implementation of 'scope'?
I assume it isn't just a no-op, since I see it applied to delegate
parameters every now and then?
Yes, yes, yes, ... these are questions that all need investigation and answering.
Surely the last question doesn't need *investigation* per se?? Or do we really have no idea whatsoever as to what 'scope' currently does in dmdfe at all? T -- Meat: euphemism for dead animal. -- Flora
Jul 09 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:09 PM, H. S. Teoh via Digitalmars-d wrote:
 Surely the last question doesn't need *investigation* per se?? Or do we
 really have no idea whatsoever as to what 'scope' currently does in
 dmdfe at all?
What I'm saying is there is not a design. A design needs to be created. Figuring out where we are, where we need to get to, and how to get there is what is needed. Please help.
Jul 09 2014
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 9 Jul 2014 13:09:30 -0700
schrieb "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>:

 Speaking
of which, what *is* the current extent of the implementation of
'scope'? I assume it isn't just a no-op, since I see it applied to
delegate parameters every now and then?  
Yes, yes, yes, ... these are questions that all need investigation and answering.
Surely the last question doesn't need *investigation* per se?? Or do we really have no idea whatsoever as to what 'scope' currently does in dmdfe at all?
So this was not a rhetoric question? For delegates scope can prevent closure heap allocation. For all other types it does nothing. Example: import std.stdio; void testA(void delegate() cb) { cb(); } void testB(scope void delegate() cb) { cb(); } void main() { int a; void callback() {a = 42;} //Callback accesses a, testA might store a reference to callback //->a might be accessible after this main function returns //->can't keep it on the stack. Allocate a on the heap testA(&callback); //Callback accesses a, but testB does not store a reference //as it tells us by using scope //So as soon as testB returns, there's no reference to a floating //around and we can allocate a on the stack. //(Of course as long as we call testA in this function, a is always on // the heap. but if we only call testB it can be on the stack) testB(&callback); }
Jul 09 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jul 09, 2014 at 11:33:09PM +0200, Johannes Pfau via Digitalmars-d wrote:
[...]
 For delegates scope can prevent closure heap allocation. For all other
 types it does nothing. Example:
 
 import std.stdio;
 
 void testA(void delegate() cb)
 {
     cb();
 }
 void testB(scope void delegate() cb)
 {
     cb();
 }
 
 void main()
 {
     int a;
     void callback() {a = 42;}
 //Callback accesses a, testA might store a reference to callback
 //->a might be accessible after this main function returns
 //->can't keep it on the stack. Allocate a on the heap
     testA(&callback); 
 
 //Callback accesses a, but testB does not store a reference
 //as it tells us by using scope
 //So as soon as testB returns, there's no reference to a floating
 //around and we can allocate a on the stack.
 //(Of course as long as we call testA in this function, a is always on
 // the heap. but if we only call testB it can be on the stack)
     testB(&callback);
 }
Unfortunately, it seems that this is not enforced by the compiler at all. For example: int delegate() globDg; void func(scope int delegate() dg) { globDg = dg; // shouldn't compile, but does globDg(); } void sub() { int x; func(() { return ++x; }); // oops } void trashme() { import std.stdio; writeln(globDg()); // prints garbage } void main() { sub(); trashme(); } If 'scope' is commented out, then it works as expected (i.e., x gets allocated on the heap). https://issues.dlang.org/show_bug.cgi?id=13085 T -- Dogs have owners ... cats have staff. -- Krista Casada
Jul 09 2014
prev sibling next sibling parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 07/10/14 00:16, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Jul 09, 2014 at 11:33:09PM +0200, Johannes Pfau via Digitalmars-d
wrote:
 [...]
 For delegates scope can prevent closure heap allocation. For all other
 types it does nothing. Example:

 import std.stdio;

 void testA(void delegate() cb)
 {
     cb();
 }
 void testB(scope void delegate() cb)
 {
     cb();
 }

 void main()
 {
     int a;
     void callback() {a = 42;}
 //Callback accesses a, testA might store a reference to callback
 //->a might be accessible after this main function returns
 //->can't keep it on the stack. Allocate a on the heap
     testA(&callback); 

 //Callback accesses a, but testB does not store a reference
 //as it tells us by using scope
 //So as soon as testB returns, there's no reference to a floating
 //around and we can allocate a on the stack.
 //(Of course as long as we call testA in this function, a is always on
 // the heap. but if we only call testB it can be on the stack)
     testB(&callback);
 }
Unfortunately, it seems that this is not enforced by the compiler at all.
Yes, scope is not enforced at all. Also: void main() { int a; auto callback = {a = 42;}; // heap alloc scope callback = {a = 42;}; // stack (ie normal) alloc testA(callback); testB(callback); } Then there are lazy args, which are basically scope delegates, but with no way to turn off 'scope' and no escape protection. Trying to tack 'borrowed' on 'ref' is not a good idea. (would require new restrictions, hence not backwards compatible; it can't be a safe-only thing, `borrowed` affects lifetimes etc) artur
Jul 09 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jul 09, 2014 at 03:16:37PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
 	https://issues.dlang.org/show_bug.cgi?id=13085
[...] Hmm, apparently, this is a long-standing known issue: https://issues.dlang.org/show_bug.cgi?id=5270 Judging from this, a big missing piece of the current implementation is the actual enforcement of 'scope'. So here's a first stab at refining (and extending) what 'scope' should be: - 'scope' can be applied to any variable, and is part of its type. Let's call this a "scoped type", and a value of this type a "scoped value". - Every scoped type has an associated lifetime, which is basically the scope in which it is declared. - The lifetime of a scoped variable is PART OF ITS TYPE. - An unscoped variable is regarded to have infinite lifetime. - For function parameters, this lifetime is the scope of the function body. - For local variables, the lifetime is the containing lexical scope where it is declared. - Taking the address of a scoped value returns a scoped pointer, whose lifetime is the lexical scope where the address-of operator is used. - A scoped type can only be assigned to another scoped type of identical or narrower lifetime. Basically, the idea here is that a scoped value can only have its scope narrowed, never expanded. In practice, this means: - If a scoped type is a reference type (class or pointer or ref), it can only be assigned to another scoped type whose associated lifetime is equal or contained within the source value's associated lifetime. - If a scoped type is a value type with indirections, it can only be assigned to an lvalue of the same scoped type (with the same associated lifetime). - If a scoped type is a value type with no indirections, it's freely assignable to a non-scoped lvalue of compatible type. - A function's return type can be scoped (not sure what syntax to use here, since it may clash with scope delegates). - The lifetime of the return value is the containing scope of the function definition -- if it's a module-level function, then its lifetime is infinite. If it's an inner function, then its lifetime is the containing lexical scope of its definition. Example: class C {} void func() { // return type of helper is scope(C) with lifetime up to // the end of func's body. scope(C) helper() { ... } } - Returning a value from a function is considered to be equivalent to assigning the value to a variable of the return type of the function. Thus: class C {} void func() { scope(C) c1; // helper's return type has lifetime == func's body scope(C) helper() { scope(C) c2; if (cond) return c1; // OK, c1's lifetime == func's body else return c2; // ILLEGAL: c2's lifetime < func's body } } - Since a scoped return type has its lifetime as part of its type, the type system ensures that scoped values never escape their lifetime. For example, if we are sneaky and return a pointer to an inner function, the type system will prevent leakage of the scoped value: class C {} auto func() { scope(C) c1; // Return type of sneaky is scope(C) with lifetime = // body of func. scope(C) sneaky() { // This is OK, because c1's lifetime == body of // func, which is compatible with its return type. return c1; } // Aha! we now we have broken scope... or have we? return &sneaky; } void main() { // Let's see. Get a function pointer to a function that // "leaks" a scoped value... auto funcptr = func(); // But this doesn't compile, because the return type of // funcptr() is a scoped variable whose lifetime is // inside the body of func(), but since we're outside of // func here, the lifetime of x doesn't match the // lifetime of funcptr()'s return value, so the // following assignment is rejected as having // incompatible types: auto x = funcptr(); // This will actually work... but it's OK, because we // aren't actually storing the return value of // funcptr(), so the scoped value is actually not leaked // after all. funcptr(); } - Aggregates: - It's turtles all the way down: members of scoped aggregates also have scoped type, with lifetime inherited from the parent aggregate. In other words, the lifetime of the aggregate is transitive to the lifetime of its members. For example: class C {} struct S { C c; int x; } int func(scope S s) { // N.B. lifetime of s is func's body. auto c1 = s.c; // typeof(c1) == scope(C) with lifetime = func's body C d; d = c1; // illegal: c1 has shorter lifetime than d. return s.x; // OK, even though typeof(s.x) has lifetime = // func's body, it's a value type so we're // actually copying it to func's return value, // not returning the actual scoped int. } - Passing parameters: since unscoped values are regarded to have infinite lifetime, it's OK to pass unscoped values into scoped function parameters: it's a narrowing of lifetime of the original value, which is allowed. (What's not allowed is expanding the lifetime of a scoped value.) I'm sure there are plenty of holes in this proposal, so destroy away. ;-) T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Jul 09 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 10/07/14 01:57, H. S. Teoh via Digitalmars-d wrote:

 [...]
 I'm sure there are plenty of holes in this proposal, so destroy away.
 ;-)
You should post this in a new thread. I'm wondering if a lot more data can be statically allocated. Then passed by reference to functions taking scope parameters. This should be safe since the parameter is guaranteed to outlive the function call. -- /Jacob Carlborg
Jul 10 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 9 July 2014 at 23:58:39 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 So here's a first stab at refining (and extending) what 'scope' 
 should be:
In general, I like it, but can scopedness be inferred? The impression I get from this is we're supposed to manually annotate every scoped everything, which IMO kind of moots the benefits in a broad sense. If it _cannot_ be inferred (even if imperfectly), then I wonder if it doesn't make more sense to invert the proposed default and require annotation when scope restrictions need to be eased. The ideal seems like it could be a major blow against non-local errors, but relying on convention isn't desirable. Of course, in fairness, I may be misunderstanding the application of this entirely...? -Wyatt
Jul 10 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 4:57 PM, H. S. Teoh via Digitalmars-d wrote:
 I'm sure there are plenty of holes in this proposal, so destroy away.
 ;-)
How about making a DIP out of this? (And thanks for making a proposal!)
Jul 10 2014
prev sibling next sibling parent reply "Remo" <remo4d gmail.com> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 Distilling the discussions about D that are elsewhere than this 
 forum, some consistent themes emerge which we need to address 
 to broaden the appeal of D. All of them require some 
 organization and focussed effort to complete.

 There's been enough jawboning about them. I figure all of them 
 can be smartly blown to smithereens if we just line up 3 or 4 
 cannons on each.


 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here. But a ref counted object should work, and 
 would be very attractive, much like C++'s shared_ptr<T>.


 2. Unique References

 unique_ptr<T> is another big success for C++. 2.066 has already 
 made big strides in inferring uniqueness of expressions, but it 
 doesn't go so far as creating a Unique!T type.


 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape 
 analysis, too.


 4. Eliminating gratuitous use of GC in Phobos

 This means allocations that are not transmitted back to the 
 user. Here's an example of such: 
 https://github.com/D-Programming-Language/phobos/pull/2014


 5. Precise and Concurrent GC

 There's been a lot of work on this, but I don't know where we 
 stand on it.


 6. Pushing decisions about storage allocation upwards out of 
 Phobos

 By having functions write to OutputRanges instead of to GC 
 allocated buffers, the user can decide how to allocate the 
 storage.


 7. "D-Routines" - goroutines for D

 Goroutines are the killer feature of Go for a number of 
 sensible people. We pretty much have this already with fibers, 
 but what is lacking is a scheduler, which will take some 
 effort, and a "Channel" type, which should be easy.


 8. NotNull!T type

 For those that want a non-nullable reference type. This should 
 be doable as a library type.
All of this would be great, especially 1 and 2. unique_ptr<T> is helpful in 90% of the time. shared_ptr<T> is necessary in may be another 9%. Memory pool is helpful in another cases. And only in 0.1% case GC is really needed. :) So how about memory pool for D ? It there already one ?
 What about the already present std.typecons.Unique?
Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code.
Jul 08 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Remo:

 unique_ptr<T> is helpful in 90% of the time.
 shared_ptr<T> is necessary in may be another 9%.
 Memory pool is helpful in another cases.
 And only in 0.1% case GC is really needed. :)
Are you forgetting the RefCount? But I use D because it has a GC and it doesn't look like C++, I am not writing device drivers or an operating system, I am OK with a language less efficient than C++ if it gives easier to write code, more compact code, less noisy code, much less bug-prone code. In C++11 you have over-engineered lambdas because there is no GC, D GC rely on the GC and sometimes allocate on the heap. I don't want the very bad syntax and semancits of C++ lambdas in D. Closures and lambdas are quite common in the D code I write. How do you concatenate built-in arrays without GC? And so on...
 So how about memory pool for D ?
 It there already one ?
Andrei is working a lot on them. They look very good. Bye, bearophile
Jul 08 2014
parent reply "Remo" <remo4d gmail.com> writes:
On Tuesday, 8 July 2014 at 22:56:56 UTC, bearophile wrote:
 Remo:

 unique_ptr<T> is helpful in 90% of the time.
 shared_ptr<T> is necessary in may be another 9%.
 Memory pool is helpful in another cases.
 And only in 0.1% case GC is really needed. :)
Are you forgetting the RefCount?
shared_ptr<T> uses reference counting. http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_ptr.htm
 But I use D because it has a GC and it doesn't look like C++, I 
 am not writing device drivers or an operating system, I am OK 
 with a language less efficient than C++ if it gives easier to 
 write code, more compact code, less noisy code, much less 
 bug-prone code.
I do not saying that GC is always bad. The future C++ standard will get GC too. It is strange but some peoples (not C++ programmers) think that D looks too much like C++ and this is bad :) For this is advantage that D looks a bit like C++ and can interact/work with C/C++ ! I like a lot of D features. Templates for example are probably easier to write in D as in C++, but I still do not have problems with them in both languages. So if I want to write a simple tool then I would use D2 instate of C++. But everything (like a 3D Renderer) that need to be as fast as possible can still only be written in C++.
 In C++11 you have over-engineered lambdas because there is no 
 GC, D GC rely on the GC and sometimes allocate on the heap. I 
 don't want the very bad syntax and semancits of C++ lambdas in 
 D. Closures and lambdas are quite common in the D code I write.
Well yes may be the lambdas syntax in C++ is not the best but it is still great addition to the language.
 How do you concatenate built-in arrays without GC? And so on...
The same way one do this in C++ ? Copy second array at the end of the first one. If there is not enough free space in the fist array (a) then. Allocate new array bigger as size of (a+b) and copy array (a) and (b) to the new memory, then free old memory. This work reasonable well for std::vector<T> . And how this will be done with GC ?
 So how about memory pool for D ?
 It there already one ?
Andrei is working a lot on them. They look very good.
Is the code public already ?
 Bye,
 bearophile
Jul 08 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 8 July 2014 at 23:18:53 UTC, Remo wrote:
 So how about memory pool for D ?
 It there already one ?
Andrei is working a lot on them. They look very good.
Is the code public already ?
https://github.com/andralex/std_allocator
Jul 08 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote:
 https://github.com/andralex/std_allocator
This is much more recent: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
Jul 08 2014
prev sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote:
 Is the code public already ?
https://github.com/andralex/std_allocator
Maybe Andrei should remove this outdated version to reduce confusion, if nobody uses it that is :) /Per
Jul 11 2014
prev sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 08/07/2014 23:40, Remo wrote:
 What about the already present std.typecons.Unique?
Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code.
I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 8:38 AM, Nick Treleaven wrote:
 On 08/07/2014 23:40, Remo wrote:
 What about the already present std.typecons.Unique?
Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code.
I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308
More things that need to happen with Unique: Unique!T u = ...; immutable p = u; // unique references can be implicitly cast to immutable Unique!(int*) u = new int; // must work int* p = new int; Unique!(int*) u = p; // must fail
Jul 09 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/9/14, 12:55 PM, Walter Bright wrote:
 On 7/9/2014 8:38 AM, Nick Treleaven wrote:
 On 08/07/2014 23:40, Remo wrote:
 What about the already present std.typecons.Unique?
Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code.
I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit: https://github.com/D-Programming-Language/phobos/pull/2308
More things that need to happen with Unique: Unique!T u = ...; immutable p = u; // unique references can be implicitly cast to immutable
Hmmm... how about using u after that? Andrei
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
Jul 09 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/9/14, 1:51 PM, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei
Jul 09 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 2:47 PM, Andrei Alexandrescu wrote:
 On 7/9/14, 1:51 PM, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei
Is there a good reference on that disaster?
Jul 09 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/9/14, 3:25 PM, Walter Bright wrote:
 On 7/9/2014 2:47 PM, Andrei Alexandrescu wrote:
 On 7/9/14, 1:51 PM, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei
Is there a good reference on that disaster?
https://www.google.com/search?q=std%20auto_ptr%20sucks&gws_rd=ssl :o) It was the one library artifact that was deemed sufficiently bad for C++ to be straight deprecated. They didn't attempt that even with iostreams. Andrei
Jul 09 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu 
wrote:
 On 7/9/14, 1:51 PM, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei
The problem with auto_ptr is that people rarely used it for what it was designed for. Probably because it was the only smart pointer in the STL. As I'm sure you're aware, the purpose of auto_ptr is to explicitly define ownership transfer of heap data. For that it's pretty much perfect, and I use it extensively. It looks like unique_ptr is pretty much the same, but with a facelift. Underneath it still performs destructive copies, unless I've misread the docs.
Jul 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 7:53 AM, Sean Kelly wrote:
 On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu wrote:
 On 7/9/14, 1:51 PM, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
That semantics would reenact the auto_ptr disaster so probably wouldn't be a good choice. -- Andrei
The problem with auto_ptr is that people rarely used it for what it was designed for. Probably because it was the only smart pointer in the STL. As I'm sure you're aware, the purpose of auto_ptr is to explicitly define ownership transfer of heap data. For that it's pretty much perfect, and I use it extensively. It looks like unique_ptr is pretty much the same, but with a facelift. Underneath it still performs destructive copies, unless I've misread the docs.
Nononono - unique_ptr never moves from lvalues. Also, the educational argument for auto_ptr doesn't stand; it was bad design, pure and simple. -- Andrei
Jul 10 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 15:51:25 UTC, Andrei Alexandrescu 
wrote:
 Nononono - unique_ptr never moves from lvalues. Also, the 
 educational argument for auto_ptr doesn't stand; it was bad 
 design, pure and simple. -- Andrei
The documentation at: http://en.cppreference.com/w/cpp/memory/unique_ptr must be incomplete. In their example they use std::move when moving the value between pointers, but there's no mention of that in the description of the type. I guess I should just check the standard. I haven't looked at it very closely because I'm stuck using a pre-C++0x compiler at work.
Jul 10 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 9 July 2014 at 20:51:04 UTC, Walter Bright wrote:
 On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
 Hmmm... how about using u after that?
Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.
So runtime error or php style better anything than nothing for something that can be checked statically...
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 12:03 AM, deadalnix wrote:
 So runtime error or php style better anything than nothing for something that
 can be checked statically...
I don't understand your comment.
Jul 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 12:21 AM, Walter Bright wrote:
 On 7/10/2014 12:03 AM, deadalnix wrote:
 So runtime error or php style better anything than nothing for
 something that
 can be checked statically...
I don't understand your comment.
It's very simple. The semantics you propose is move with the syntax of copy. Following the implicit move, the source of it is surprisingly modified (emptied). That doesn't work. There is a humongous body of knowledge accumulated in C++ with std::auto_ptr. That artifact has been quite the show, including people who swore by it (!). We'd do good to simply draw from that experience instead of reenacting it. Andrei
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 6:55 AM, Andrei Alexandrescu wrote:
 On 7/10/14, 12:21 AM, Walter Bright wrote:
 On 7/10/2014 12:03 AM, deadalnix wrote:
 So runtime error or php style better anything than nothing for
 something that
 can be checked statically...
I don't understand your comment.
It's very simple. The semantics you propose is move with the syntax of copy. Following the implicit move, the source of it is surprisingly modified (emptied).
Right, that is what I proposed.
 That doesn't work. There is a humongous body of knowledge accumulated in C++
 with std::auto_ptr. That artifact has been quite the show, including people who
 swore by it (!). We'd do good to simply draw from that experience instead of
 reenacting it.
I accept that you're right, but I don't know why. I perused the link you provided earlier, and wasn't too enlightened. It was clear from those links that unique_ptr<T> is working successfully - what is different about that?
Jul 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 10:56 AM, Walter Bright wrote:
 On 7/10/2014 6:55 AM, Andrei Alexandrescu wrote:
 On 7/10/14, 12:21 AM, Walter Bright wrote:
 On 7/10/2014 12:03 AM, deadalnix wrote:
 So runtime error or php style better anything than nothing for
 something that
 can be checked statically...
I don't understand your comment.
It's very simple. The semantics you propose is move with the syntax of copy. Following the implicit move, the source of it is surprisingly modified (emptied).
Right, that is what I proposed.
 That doesn't work. There is a humongous body of knowledge accumulated
 in C++
 with std::auto_ptr. That artifact has been quite the show, including
 people who
 swore by it (!). We'd do good to simply draw from that experience
 instead of
 reenacting it.
I accept that you're right, but I don't know why. I perused the link you provided earlier, and wasn't too enlightened. It was clear from those links that unique_ptr<T> is working successfully - what is different about that?
We discussed this with Bartosz literally for weeks (him being a fan of auto_ptr for too long, later completely converted against it and I take credit for that :o)). With auto_ptr this was possible: auto_ptr<int> a(new int); auto_ptr<int> b = a; It would nullify a with copy syntax. That code won't compile with unique_ptr; you'd need an explicit move(a). It only got worse from there: passing into functions, member variables... MOVING WITH COPY SYNTAX DOES NOT WORK. It's cut and dried. Andrei
Jul 10 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 11:39:57AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 We discussed this with Bartosz literally for weeks (him being a fan of
 auto_ptr for too long, later completely converted against it and I
 take credit for that :o)). With auto_ptr this was possible:
 
 auto_ptr<int> a(new int);
 auto_ptr<int> b = a;
 
 It would nullify a with copy syntax. That code won't compile with
 unique_ptr; you'd need an explicit move(a).
 
 It only got worse from there: passing into functions, member
 variables...
Yep, if you pass auto_ptr into a function, it goes poof after the function returns; the original reference is gone.
 MOVING WITH COPY SYNTAX DOES NOT WORK.
 
 It's cut and dried.
[...] I independently invented my own version of auto_ptr many years ago, before auto_ptr got into the standard. Basically, the idea was to annotate pointers into two classes: "owner" (i.e., auto_ptr) and "reference" (i.e., "regular" pointer). Ownership is unique, so passing owner pointers has destructive copy semantics (it "transfers ownership" to the callee), whereas passing reference pointers simply makes a copy. The rule was that copying only works one way: you can only copy an owner pointer into a reference pointer, but never the other way around. The thought was that somebody keeps a master reference to an object, assuming ownership over it, whereas others may keep as many references to it as they want, but they cannot perform owner-specific operations (like free()). Ownership may be transferred to those who are prepared to assume the responsibility of managing the object; such transfers involve destructive copy (the original owner no longer holds the rights to the object, so to speak) -- though non-owner references to that object remain valid. Thus, passing an owner pointer into a function that expects a reference pointer simply makes a copy out of it (non-destructive), whereas passing a reference pointer where an owner is expected is illegal. (Though, of course, at the time I didn't have the means to actually enforce this, so it was merely a convention.) With this annotation, function signatures became more self-documenting: class Object { ... } // Argument is a reference pointer; function doesn't expect // ownership transfer. int computeValue(ref Object *obj); // Argument is an owner pointer; i.e., the pointer is invalid // after the function returns. The function will assume // ownership of the pointer and call free(), etc., when it's // done. void addToCache(owner Object *obj); int main(int argc, char *argv[]) { owner Object *obj = new Object; // new returns an owner pointer ref Object *ref = obj; // OK, makes a copy of the pointer obj = ref; // ILLEGAL: cannot assign owner to ref int x = computeValue(ref); // OK, function expects ref x = computeValue(obj); // OK, owner implicitly converts to ref addToCache(ref); // ILLEGAL: ref doesn't convert to owner addToCache(obj); // OK: transfers ownership of obj to function // N.B. from here on, obj is now invalid, and any // dereference is a bug until it's assigned a fresh // owner pointer. obj = new Object; // OK, create another object free(ref); // ILLEGAL: can only free owner pointers free(obj); // OK, transfers ownership to free // From here on, obj is again invalid, and any further // dereference is a bug. owner Object *obj2 = new Object; obj = obj2; // OK, transfers ownership to obj. // Now obj2 is invalid and should not be dereferenced. } One thing that my system didn't address, though, was the problem of dangling reference pointers after the corresponding owner pointers have been freed. That remains an unsolved problem within that system, and ultimately, requires some form of GC to adequately address. Destructive copy, however, is tricky business; if one is not careful, one easily ends up with invalid owner pointers in the wrong places, so I agree with the sentiment of '=' being poor notation for destructive copy. Having owner pointers implicitly convert to ref pointers, however, mostly mitigates the problem -- for the most part, pointer assignments do not involve transfer of ownership, so the usual (ref) pointer semantics with non-destructive copy apply. When manipulating owner pointers, you have to be extremely careful to begin with, so generally you'd pay more attention to how it's done -- and hopefully catch problematic assignments of owner pointers. T -- Without outlines, life would be pointless.
Jul 10 2014
prev sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 09/07/2014 20:55, Walter Bright wrote:
 here's the first one,
 to disable postblit:

 https://github.com/D-Programming-Language/phobos/pull/2308
BTW I updated that pull, should be less muddled now ;-)
 More things that need to happen with Unique:
...
    Unique!(int*) u = new int;   // must work
That works, it's spelled: Unique!int u = new int;
    int* p = new int;
    Unique!(int*) u = p;         // must fail
The existing design actually allows that, but nulls p: int* p = new int; Unique!int u = p; // ok assert(p is null); assert(!u.isEmpty); If there are aliases of p before u is constructed, then u is not the sole owner of the reference (mentioned in the docs): Also related is whether we use alias this to expose the resource (allowing mutation but not replacement) or if we use opDispatch. Currently, it uses opDot, which AFAICT is basically opDispatch. If we use alias this, that's a(nother) hole exposing non-unique access to the resource. BTW, should isEmpty be documented? It seems to be public ATM.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 9:00 AM, Nick Treleaven wrote:
 On 09/07/2014 20:55, Walter Bright wrote:
 here's the first one,
 to disable postblit:

 https://github.com/D-Programming-Language/phobos/pull/2308
BTW I updated that pull, should be less muddled now ;-)
 More things that need to happen with Unique:
...
    Unique!(int*) u = new int;   // must work
That works, it's spelled: Unique!int u = new int;
I'm unconfortable with that design, as T can't be a class ref or a dynamic array.
    int* p = new int;
    Unique!(int*) u = p;         // must fail
The existing design actually allows that, but nulls p: [...] If there are aliases of p before u is constructed, then u is not the sole owner of the reference (mentioned in the docs):
Exactly. It is not checkable and not good enough. Note that as of 2.066 the compiler tests for uniqueness of an expression by seeing if it can be implicitly cast to immutable. It may be possible to do that with Unique without needing compiler modifications.
 Also related is whether we use alias this to expose the resource (allowing
 mutation but not replacement) or if we use opDispatch. Currently, it uses
opDot,
 which AFAICT is basically opDispatch. If we use alias this, that's a(nother)
 hole exposing non-unique access to the resource.
The holes must be identified and closed. BTW, I'm amenable to adjusting the compiler to recognize Unique and help out as a last resort.
Jul 10 2014
parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 10/07/2014 19:03, Walter Bright wrote:
 On 7/10/2014 9:00 AM, Nick Treleaven wrote:
 On 09/07/2014 20:55, Walter Bright wrote:
    Unique!(int*) u = new int;   // must work
That works, it's spelled: Unique!int u = new int;
I'm unconfortable with that design, as T can't be a class ref or a dynamic array.
It does currently work with class references, but not dynamic arrays: Unique!Object u = new Object; It could be adjusted so that all non-value types are treated likewise: Unique!(int[]) v = [1, 3, 2];
    int* p = new int;
    Unique!(int*) u = p;         // must fail
The existing design actually allows that, but nulls p:
> [...]
 If there are aliases of p before u is constructed, then u is not the
 sole owner
 of the reference (mentioned in the docs):

Exactly. It is not checkable and not good enough.
In that case we'd need to deprecate Unique.this(ref RefT p) then.
 Note that as of 2.066 the compiler tests for uniqueness of an expression
 by seeing if it can be implicitly cast to immutable. It may be possible
 to do that with Unique without needing compiler modifications.
Current Unique has a non-ref constructor that only takes rvalues. Isn't that good enough to detect unique expressions?
 Also related is whether we use alias this to expose the resource
 (allowing
 mutation but not replacement) or if we use opDispatch. Currently, it
 uses opDot,
 which AFAICT is basically opDispatch. If we use alias this, that's
 a(nother)
 hole exposing non-unique access to the resource.
The holes must be identified and closed.
OK, opDispatch then.
 BTW, I'm amenable to adjusting the compiler to recognize Unique and help
 out as a last resort.
Jul 11 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2014 4:44 AM, Nick Treleaven wrote:
 On 10/07/2014 19:03, Walter Bright wrote:
 On 7/10/2014 9:00 AM, Nick Treleaven wrote:
 On 09/07/2014 20:55, Walter Bright wrote:
    Unique!(int*) u = new int;   // must work
That works, it's spelled: Unique!int u = new int;
I'm unconfortable with that design, as T can't be a class ref or a dynamic array.
It does currently work with class references, but not dynamic arrays: Unique!Object u = new Object; It could be adjusted so that all non-value types are treated likewise: Unique!(int[]) v = [1, 3, 2];
    int* p = new int;
    Unique!(int*) u = p;         // must fail
The existing design actually allows that, but nulls p:
> [...]
 If there are aliases of p before u is constructed, then u is not the
 sole owner
 of the reference (mentioned in the docs):

Exactly. It is not checkable and not good enough.
In that case we'd need to deprecate Unique.this(ref RefT p) then.
 Note that as of 2.066 the compiler tests for uniqueness of an expression
 by seeing if it can be implicitly cast to immutable. It may be possible
 to do that with Unique without needing compiler modifications.
Current Unique has a non-ref constructor that only takes rvalues. Isn't that good enough to detect unique expressions?
No, see the examples I gave earlier.
Jul 11 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should 
 be doable as a library type.
I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it. [0]: http://forum.dlang.org/post/lcjg43$2vq1$1 digitalmars.com
Jul 08 2014
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 9 July 2014 at 00:25:55 UTC, Meta wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should 
 be doable as a library type.
I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it. [0]: http://forum.dlang.org/post/lcjg43$2vq1$1 digitalmars.com
Also, a lot of people seem to be complaining lately (or at DConf, at least) about debugging mixins, template expansions, template constraints?, etc. ...And I was going to mention the proposed __ctfeWriteln, but it seems that it's already in Druntime. When did that happen?
Jul 08 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here. But a ref counted object should work, and 
 would be very attractive, much like C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Jul 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2014 6:01 PM, Mike wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed extensively here.
 But a ref counted object should work, and would be very attractive, much like
 C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it?
Jul 08 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
 On 7/8/2014 6:01 PM, Mike wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here.
 But a ref counted object should work, and would be very 
 attractive, much like
 C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it?
Well, for starters RefCounted doesn't work with classes. That needs to be implemented. I'm not sure what was problematic about implementing it for classes though (anyone reading know?). Secondly, a lot of things need to be extracted from std.grabbag (AKA std.typecons) and put in modules with names that are much more obvious. Nobody thinks to check "typecons" (whatever that means)* but it contains some of the most useful general purpose features in Phobos. It has Tuple, Unique, RefCounted, Scoped, Nullable, and more all buried away in an unexpected module. I propose just stealing C++'s structure when possible (so std.tuple and std.memory for starters). * Yes, I know it means Type Constructors. That isn't clear the first time someone reads the name though.
Jul 08 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 9 July 2014 at 03:18:54 UTC, Brad Anderson wrote:
 Well, for starters RefCounted doesn't work with classes. That
 needs to be implemented. I'm not sure what was problematic about
 implementing it for classes though (anyone reading know?).
idk if this is what the Phobos devs were thinking, but my own attempts have hit a few snags: 1) double indirection with the naive solution: struct { Object o; int refcount; }. Pretty easily fixed by emplacing the class though so no big deal but phobos didn't seem to attempt this so maybe that was a problem there. 2) It messes up implicit casting. And this is a big deal because I don't think there's a solution: alias this can help with the base class, but can't handle the multiple requirements of classes that implement several interfaces. If you alias this to the payload, it would accomplish everything... but then the reference is no longer counted, allowing it to escape and still point to freed memory. Multiple alias this is prolly a solution to the problem.
 Secondly, a lot of things need to be extracted from std.grabbag
 (AKA std.typecons) and put in modules with names that are much
 more obvious. Nobody thinks to check "typecons"
yea I think most people don't even know this stuff exists.
Jul 08 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
 On 7/8/2014 6:01 PM, Mike wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here.
 But a ref counted object should work, and would be very 
 attractive, much like
 C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Let me put it this way:
My question was sincere, I really wanted to know more about the differences RefCounted and what you proposed.
 users all complain that D doesn't have ref counting. If 
 typecons.RefCounted works, why is this happening?  What can be 
 done to convince people that D does ref counting?
From what I've observed, I don't think users are complaining that D doesn't do ref counting. I believe they are complaining that D doesn't do pervasive automatic reference counting. RefCounted can't be used with D's built-in types, right? IMO users are complaining that the current mark-and-sweep GC is not suitable for certain applications, and they want something that is. The solution that comes to their mind is pervasive ARC, so that's what they say they want. And because they can't actually try it for themselves, they aren't convinced it's not a feasible solution (It would be nice to see some measurable results). If RefCounted is intended to have shared_ptr<T> semantics, then it does appear D does reference counting, but I believe it's pervasive automatic reference counting that users really want to try.
  If [std.typecons.RefCounted] doesn't work, what needs to be 
 done to fix it?
RefCounted or any other library solution can't be used with D's built-in types, right? Also, it forces users to change their patterns and idioms. I consider these drawbacks, and don't see any solution except to provide an alternative GC implementation. Mike
Jul 08 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 9 July 2014 at 04:12:50 UTC, Mike wrote:
 My question was sincere, I really wanted to know more about the 
 differences  RefCounted and what you proposed.
shared_ptr supports multi-threading, weak pointers and destructors.
 If RefCounted is intended to have shared_ptr<T> semantics,
Nowhere near the same semantics: http://en.cppreference.com/w/cpp/memory/shared_ptr
Jul 08 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/8/2014 9:12 PM, Mike wrote:
  From what I've observed, I don't think users are complaining that D doesn't do
 ref counting.
The recurrent observation is "I use C++/Rust/Whatever because they do ref counting, and D uses GC. Therefore I cannot use D."
 I believe they are complaining that D doesn't do pervasive
 automatic reference counting.
ARC has been extensively studied and debated at great length for D. It is not going to work for D. Nobody has figured out a way to make it work for D. Let's move on to what will work.
 RefCounted can't be used with D's built-in types, right?
The question doesn't make sense. What is a ref counted int?
 IMO users are complaining that the current mark-and-sweep GC is not suitable
for
 certain applications, and they want something that is.  The solution that comes
 to their mind is pervasive ARC, so that's what they say they want.  And because
 they can't actually try it for themselves, they aren't convinced it's not a
 feasible solution (It would be nice to see some measurable results).
We've been over this ground many, many times. Saying people want ARC is correct. Nobody has proposed a feasible design or a way to get to one (I failed at that, too).
 If RefCounted is intended to have shared_ptr<T> semantics, then it does appear
D
 does reference counting, but I believe it's pervasive automatic reference
 counting that users really want to try.
There's no known way to get ARC in D.
Jul 08 2014
next sibling parent "Mike" <none none.com> writes:
On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote:
 On 7/8/2014 9:12 PM, Mike wrote:
 From what I've observed, I don't think users are complaining 
 that D doesn't do
 ref counting.
The recurrent observation is "I use C++/Rust/Whatever because they do ref counting, and D uses GC. Therefore I cannot use D." ARC has been extensively studied and debated at great length for D. It is not going to work for D. Nobody has figured out a way to make it work for D. Let's move on to what will work.
Agreed. I'm just trying to clarify the problem. I believe ARC and a reference counted library type are quite different solutions to different problems. Adding a ref counted library type, will likely not stop the clamoring.
 RefCounted can't be used with D's built-in types, right?
The question doesn't make sense. What is a ref counted int?
I meant exceptions, dynamic arrays, etc... that are instantiated in the D runtime and expect an automatic memory manager of some type to exist. I don't see how one can use a reference counted library type like RefCounted for these. Feel free to correct me, if I'm wrong. Mike
Jul 08 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote:
 The question doesn't make sense. What is a ref counted int?
From the typecons documentation: Example: // A pair of an $(D int) and a $(D size_t) - the latter being the // reference count - will be dynamically allocated auto rc1 = RefCounted!int(5); :-)
Jul 08 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
 On 7/8/2014 6:01 PM, Mike wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here.
 But a ref counted object should work, and would be very 
 attractive, much like
 C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it?
I think the problem is that people like to have reference semantics for ressources but only struct support deterministic destruction, and are value types.. If Unique and RefCounted were a bit more usable people interested in deterministic release (ie. almost everyone) could drop using classes for resources and live happily.
Jul 09 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
 On 7/8/2014 6:01 PM, Mike wrote:
 On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here.
 But a ref counted object should work, and would be very 
 attractive, much like
 C++'s shared_ptr<T>.
How does this differ from std.typecons.RefCounted?
Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it?
For me the simple "works or not" test question is "can you do reference counted exceptions?". Right now it is impossible AFAIK.
Jul 09 2014
prev sibling next sibling parent "Puming" <zhaopuming gmail.com> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

 7. "D-Routines" - goroutines for D

 Goroutines are the killer feature of Go for a number of 
 sensible people. We pretty much have this already with fibers, 
 but what is lacking is a scheduler, which will take some 
 effort, and a "Channel" type, which should be easy.
vibe.d has something similar, which could go into the standard library IMHO: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d
Jul 08 2014
prev sibling next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 5. Precise and Concurrent GC

 There's been a lot of work on this, but I don't know where we 
 stand on it.
The precise work is held up by: https://github.com/D-Programming-Language/dmd/pull/2480 The GC is due for a redesign / reimplementation.
Jul 09 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Some minor disagreements:

On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 2. Unique References

 unique_ptr<T> is another big success for C++. 2.066 has already 
 made big strides in inferring uniqueness of expressions, but it 
 doesn't go so far as creating a Unique!T type.
 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape 
 analysis, too.
Last time we talked about it during dconf you have mentioned doing necessary escape analysis for borrowing semantics is too complicated to consider :) Ad if you don't mean transitive, you shouldn't refer to Rust borrowing terminology as any ownership type is normally transitive there.
 5. Precise and Concurrent GC

 There's been a lot of work on this, but I don't know where we 
 stand on it.
I have started work on porting the CDGC to D2, have compilable version (that was easy thanks to earlier Sean work) but updating implementation to match new druntime and pass tests will take quite some time.
 7. "D-Routines" - goroutines for D

 Goroutines are the killer feature of Go for a number of 
 sensible people. We pretty much have this already with fibers, 
 but what is lacking is a scheduler, which will take some 
 effort, and a "Channel" type, which should be easy.
I'd state it differently: "Marketing fuss about goroutines is the killer feature of Go" :) It does not have any fundamental advantage over existing actor model and I doubt it will matter _that_ much.
 8. NotNull!T type

 For those that want a non-nullable reference type. This should 
 be doable as a library type.
I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.
Jul 09 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 I don't know where it comes from but non-nullable reference 
 type has ZERO value if it is not the default one.
This article talks about switching to NotNull on default in real (small) Java projects (you have to add a NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
Jul 09 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote:
 Dicebot:

 I don't know where it comes from but non-nullable reference 
 type has ZERO value if it is not the default one.
This article talks about switching to NotNull on default in real (small) Java projects (you have to add a NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
Yes and this is exactly what we can't do in D. So what is the point of discussing library NonNull then?
Jul 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 Yes and this is exactly what we can't do in D.
I don't understand, if they can do that with Java, why not D? Bye, bearophile
Jul 09 2014
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 18:09:58 UTC, bearophile wrote:
 Dicebot:

 Yes and this is exactly what we can't do in D.
I don't understand, if they can do that with Java, why not D? Bye, bearophile
Java bytecode reflection makes possible to find all reference types in an attributed package and replace them to non-nullables. D compile-time reflection is currently limited to declaration (with a very 1few exceptions) - I am not aware of any ways to do it other than hot-patching generated machine code (not really an option). One thing we can do is to validate that there are no nullable references in public signatures but this is something more suitable for static analysis rule anyway.
Jul 09 2014
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote:
 Dicebot:

 I don't know where it comes from but non-nullable reference 
 type has ZERO value if it is not the default one.
This article talks about switching to NotNull on default in real (small) Java projects (you have to add a NonNullByDefault at package level to change the default): http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
I've used the Eclipse annotations with some success when writing Java code, which I do primarily for Android these days. If we were to ever transition to non nullable references by default, annotations would be a good way to make that transition. notnull can be used to disallow setting null on references, so it can check for things like initialising a non-nullable reference in a constructor. nullable would available for doing what is already true for references. Then Option(T) could be available as a library solution, which can hold a nullable inside it and perform the necessary runtime checking and casting to notnull T. Then you put things through a long deprecation cycle and the billion dollar mistake is finally corrected. There's a pipedream, anyway.
Jul 09 2014
parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 9 July 2014 at 20:49:00 UTC, w0rp wrote:
 <much yammering on>
I should note that there is some merit to having Option(T) even without T being non-nullable by default, as it at least gives you the ability to look at an API and find out where you'll need to deal with the None case. T foo(); U bar(); V baz(); Doesn't say as much as. T foo(); Option!U bar(); V baz(); Even doing these things without strong compile time checks is a big step up.
Jul 09 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 3:20 AM, Dicebot wrote:
 Last time we talked about it during dconf you have mentioned doing necessary
 escape analysis for borrowing semantics is too complicated to consider :) Ad if
 you don't mean transitive, you shouldn't refer to Rust borrowing terminology as
 any ownership type is normally transitive there.
Yes, I mean transitive, and understand what that implies.
 5. Precise and Concurrent GC

 There's been a lot of work on this, but I don't know where we stand on it.
I have started work on porting the CDGC to D2, have compilable version (that was easy thanks to earlier Sean work) but updating implementation to match new druntime and pass tests will take quite some time.
Is CDGC's Luca's earlier work on concurrent GC?
 7. "D-Routines" - goroutines for D

 Goroutines are the killer feature of Go for a number of sensible people. We
 pretty much have this already with fibers, but what is lacking is a scheduler,
 which will take some effort, and a "Channel" type, which should be easy.
I'd state it differently: "Marketing fuss about goroutines is the killer feature of Go" :) It does not have any fundamental advantage over existing actor model and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable as a
 library type.
I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.
Making it the default is impossible for D. However, class _C { ... } alias NotNull!_C C; is entirely practical. It's not unlike the common C practice: typedef struct S { ... } S; to bring S out of the tag name space.
Jul 09 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Making it the default is impossible for D.
Is it impossible any strategy analogous to the Java one, as visible in the link I've shown earlier in this thread? http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html Bye, bearophile
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 12:54 PM, bearophile wrote:
 Walter Bright:

 Making it the default is impossible for D.
Is it impossible any strategy analogous to the Java one, as visible in the link I've shown earlier in this thread? http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html
That's essentially just adding an attribute, like: nogc: to the beginning of a module. It's not making it the default.
Jul 09 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 That's essentially just adding an attribute, like:

     nogc:

 to the beginning of a module. It's not making it the default.
Is it possible & useful & good to put something like a " not_null_references:" (or a similar pragma) at the top of a module? How are differently defaulting modules going to interact with each other? module annotation to allow the use of a lighter Haskell-like syntax with the same semantics. The light syntax was so popular that later the default mode was switched with the light mode.) Bye, bearophile
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:42 PM, bearophile wrote:
 Is it possible & useful & good to put something like a " not_null_references:"
 (or a similar pragma) at the top of a module? How are differently defaulting
 modules going to interact with each other?
Exactly. I'm not seeing how this can work that well.
Jul 09 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Exactly. I'm not seeing how this can work that well.
Do you have an example where this works badly? You can require the notnull annotations on the arguments at module/package boundaries. But I think this thread tries to face too many problems in parallel. Even just the borrowing/lifetime topic is plenty large for a single discussion thread. I suggest to create single-topic threads. Bye, bearophile
Jul 10 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 That's essentially just adding an attribute, like:

     nogc:

 to the beginning of a module.
I think in the Java case it's more a package-level annotation instead of module-level one. Bye, bearophile
Jul 09 2014
prev sibling next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
 On 7/9/2014 3:20 AM, Dicebot wrote:
 I'd state it differently: "Marketing fuss about goroutines is 
 the killer feature
 of Go" :) It does not have any fundamental advantage over 
 existing actor model
 and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.
I think it still mostly comes down to marketing :-) That said, we're pretty close in D once my Scheduler pull request is accepted. Between that and the Generator type in the same pull request, we're not missing much but the weird switch syntax they have. There's still some work to do, but I think a lot of it really comes down to showing people what's already possible in D rather than writing more code.
Jul 09 2014
next sibling parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Wednesday, 9 July 2014 at 20:58:11 UTC, Sean Kelly wrote:
 On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
 On 7/9/2014 3:20 AM, Dicebot wrote:
 I'd state it differently: "Marketing fuss about goroutines is 
 the killer feature
 of Go" :) It does not have any fundamental advantage over 
 existing actor model
 and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.
I think it still mostly comes down to marketing :-) That said, we're pretty close in D once my Scheduler pull request is accepted. Between that and the Generator type in the same pull request, we're not missing much but the weird switch syntax they have. There's still some work to do, but I think a lot of it really comes down to showing people what's already possible in D rather than writing more code.
Might also be a win to make it _visible_ in the language as a first-class construct by also adding async/await syntax sugar. Joseph
Jul 09 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 3:24 PM, Joseph Cassman wrote:
 Might also be a win to make it _visible_ in the language as a first-class
 construct by also adding async/await syntax sugar.
async/await are great ideas, but are something quite different from goroutines.
Jul 09 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:58 PM, Sean Kelly wrote:
 I think it still mostly comes down to marketing :-)  That said,
 we're pretty close in D once my Scheduler pull request is
 accepted.  Between that and the Generator type in the same pull
 request,
Ah, I didn't know you had a PR request already! Awesome!
 we're not missing much but the weird switch syntax they have.
I'm not concerned about the syntax. Any syntax we use should be "D style" syntax, not "Go style".
 There's still some work to do, but I think a lot of it
 really comes down to showing people what's already possible in D
 rather than writing more code.
I agree.
Jul 09 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 9 July 2014 at 22:28:23 UTC, Walter Bright wrote:
 On 7/9/2014 1:58 PM, Sean Kelly wrote:
 I think it still mostly comes down to marketing :-)  That said,
 we're pretty close in D once my Scheduler pull request is
 accepted.  Between that and the Generator type in the same pull
 request,
Ah, I didn't know you had a PR request already! Awesome!
 we're not missing much but the weird switch syntax they have.
I'm not concerned about the syntax. Any syntax we use should be "D style" syntax, not "Go style".
Rob Pike has said multiple times that the key/unique thing about Go is "select" and that goroutines are the easy part. I'm not entirely sure I grok what he means but we should if we're going to try and do what they got right. Atila
Jul 09 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 7:12 PM, Atila Neves wrote:
 Rob Pike has said multiple times that the key/unique thing about Go is "select"
 and that goroutines are the easy part. I'm not entirely sure I grok what he
 means but we should if we're going to try and do what they got right.
I don't know what he means, either.
Jul 09 2014
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Thursday, 10 July 2014 at 02:12:18 UTC, Atila Neves wrote:
 Rob Pike has said multiple times that the key/unique thing 
 about Go is "select" and that goroutines are the easy part. I'm 
 not entirely sure I grok what he means but we should if we're 
 going to try and do what they got right.
Select is vital for Go in the sense that without it there'd be no way to do non-blocking send/receives on channels in Go. It's much more concise than the alternative, which would be something like `if chanA is empty then foo(chanA) else if chanB is empty then bar(chanB)`. It also avoids starvation by checking the channels in a random order - unlike the previous if-else chain, which would never call bar(chanB) if chanA was always empty. It's been implemented in Rust[1] via a macro, and can be implemented in Haskell[2] without compiler support, so I'd be surprised if it wasn't already possible to implement in D. It wouldn't however be as useful as Go's until D gets message passing between fibres. Actually, an important question that should be considered: does D want actor-style concurrency, like Erlang and Akka, or CSP-style concurrency, like Rust, Go and Haskell? Or both? Deciding this would allow efforts to be more focused. I personally think either would be great, and sufficient to make me consider D for any of the work I'd currently use Go. D currently however has neither. It technically implements the actor model in std.concurrency, but using OS threads, which significantly reduces its utility (one doesn't just spawn 100k OS threads). 1. http://thornydev.blogspot.com.au/2014/03/select-over-multiple-rust-channels.html 2. http://stackoverflow.com/questions/24611801/how-to-implement-the-equivalent-of-gos-select-statement-for-haskell-stm-channel
Jul 09 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/9/14, 8:59 PM, logicchains wrote:
 On Thursday, 10 July 2014 at 02:12:18 UTC, Atila Neves wrote:
 Rob Pike has said multiple times that the key/unique thing about Go is
 "select" and that goroutines are the easy part. I'm not entirely sure
 I grok what he means but we should if we're going to try and do what
 they got right.
Select is vital for Go in the sense that without it there'd be no way to do non-blocking send/receives on channels in Go. It's much more concise than the alternative, which would be something like `if chanA is empty then foo(chanA) else if chanB is empty then bar(chanB)`. It also avoids starvation by checking the channels in a random order - unlike the previous if-else chain, which would never call bar(chanB) if chanA was always empty.
That's what I think as well.
 It's been implemented in Rust[1] via a macro, and can be implemented in
 Haskell[2] without compiler support, so I'd be surprised if it wasn't
 already possible to implement in D. It wouldn't however be as useful as
 Go's until D gets message passing between fibres.
Yah.
 Actually, an important question that should be considered: does D want
 actor-style concurrency, like Erlang and Akka, or CSP-style concurrency,
 like Rust, Go and Haskell? Or both? Deciding this would allow efforts to
 be more focused.
We already have actor-style via std.concurrency. We also have fork-join parallelism via std.parallel. What we need is a library for CSP. Andrei
Jul 09 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu 
wrote:
 We already have actor-style via std.concurrency. We also have 
 fork-join parallelism via std.parallel. What we need is a 
 library for CSP.
The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads. Think of it from the perspective of attracting Erlang programmers, or Java/Scala programmers who use Akka. If they tried out std.concurrency and found that it failed horribly when trying to spawn fifty thousand actors, they'd be unlikely to stick with the language. Message passing between lightweight threads can also be much faster than message passing between heavyweight threads; take a look at the following message-passing benchmark and compare Haskell, Go and Erlang to the languages using OS threads: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring
Jul 09 2014
next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
 On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu 
 wrote:
 We already have actor-style via std.concurrency. We also have 
 fork-join parallelism via std.parallel. What we need is a 
 library for CSP.
The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.
As Sean wrote, please check [1] or if you need it right now, Vibe can offer what you need today... --- Paolo [1] https://github.com/D-Programming-Language/phobos/pull/1910
Jul 10 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
 On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu 
 wrote:
 We already have actor-style via std.concurrency. We also have 
 fork-join parallelism via std.parallel. What we need is a 
 library for CSP.
The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.
No. I've had an outstanding pull request to fix this for quite a while now. I think there's a decent chance it will be in the next release. To be fair, that pull request mostly provides the infrastructure for changing how concurrency is handled. A fiber-based scheduler backed by a thread pool doesn't exist yet, though it shouldn't be hard to write (the big missing piece is having a dynamic thread pool). I was going to try and knock one out while on the airplane in a few days.
 Message passing between lightweight threads can also be much 
 faster than message passing between heavyweight threads; take a 
 look at the following message-passing benchmark and compare 
 Haskell, Go and Erlang to the languages using OS threads: 
 http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring
Thanks for the benchmark. I didn't have a good reference for what kind of performance capabilities to hit, so there are a few possible optimizations I've left out of std.concurrency because they didn't buy much in my own testing (like a free list of message objects). I may have to revisit those ideas with this benchmark in mind and see what happens.
Jul 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 8:13 AM, Sean Kelly wrote:
 On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
 On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu wrote:
 We already have actor-style via std.concurrency. We also have fork-join
 parallelism via std.parallel. What we need is a library for CSP.
The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.
No. I've had an outstanding pull request to fix this for quite a while now. I think there's a decent chance it will be in the next release. To be fair, that pull request mostly provides the infrastructure for changing how concurrency is handled. A fiber-based scheduler backed by a thread pool doesn't exist yet, though it shouldn't be hard to write (the big missing piece is having a dynamic thread pool). I was going to try and knock one out while on the airplane in a few days.
Sean, it is awesome that you are taking charge of this. I can't think of anyone more perfect for the job!
Jul 10 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 10/07/14 05:59, logicchains wrote:

 It's been implemented in Rust[1] via a macro, and can be implemented in
 Haskell[2] without compiler support, so I'd be surprised if it wasn't
 already possible to implement in D. It wouldn't however be as useful as
 Go's until D gets message passing between fibres.
Another use case for AST macros, which we don't have :( -- /Jacob Carlborg
Jul 10 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
 Actually, an important question that should be considered: does 
 D want actor-style concurrency, like Erlang and Akka, or 
 CSP-style concurrency, like Rust, Go and Haskell? Or both? 
 Deciding this would allow efforts to be more focused.
AFAICS D already has actor-style concurrency with vibe.d extensions for std.concurrency so this is an easy choice ;)
Jul 10 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
On Thursday, 10 July 2014 at 10:43:39 UTC, Dicebot wrote:
 On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
 Actually, an important question that should be considered: 
 does D want actor-style concurrency, like Erlang and Akka, or 
 CSP-style concurrency, like Rust, Go and Haskell? Or both? 
 Deciding this would allow efforts to be more focused.
AFAICS D already has actor-style concurrency with vibe.d extensions for std.concurrency so this is an easy choice ;)
Are there any tutorials or blog posts out there demonstrating how to use this? I think posts along the lines of "This is a CSP/message passing program in Go/Erlang. This is the same program translated into D; look how concise and faster it is!" could attract a lot of interest. Reading the code in the pull request [1], for instance, makes me wonder how to tell if `spawn()` is spawning a thread or a fibre. Can a tid refer to a fibre? If so, why's it called a thread ID, and how do I tell if a particular tid refers to a thread or fibre? It would be great to have these kinds of questions answered in an easily available reference (for instance, the documentation for std.concurrency, which currently doesn't even mention fibres or vibe.d). 1. https://github.com/D-Programming-Language/phobos/pull/1910
Jul 10 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
 Are there any tutorials or blog posts out there demonstrating 
 how to use this? I think posts along the lines of "This is a 
 CSP/message passing program in Go/Erlang. This is the same 
 program translated into D; look how concise and faster it is!" 
 could attract a lot of interest.
There are no detailed blog posts and I believe only few developers are really well proficient with this vibe.d functionality. Some relevant docs: http://vibed.org/api/vibe.core.core/ http://vibed.org/api/vibe.core.concurrency/ http://vibed.org/api/vibe.core.task/
 Reading the code in the pull request [1], for instance, makes 
 me wonder how to tell if `spawn()` is spawning a thread or a 
 fibre. Can a tid refer to a fibre? If so, why's it called a 
 thread ID, and how do I tell if a particular tid refers to a 
 thread or fibre? It would be great to have these kinds of 
 questions answered in an easily available reference (for 
 instance, the documentation for std.concurrency, which 
 currently doesn't even mention fibres or vibe.d).

 1. https://github.com/D-Programming-Language/phobos/pull/1910
Problem is that this is most simple PR to simply add message-passing support for fibers. Adding some advanced schedulers with worker thread pool can be expected to be done on top but.. This small PR has been rotting there for ages with pretty much zero attention but from few interested persons. I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now. We can't really expect anything else to improve why it stays that bad - Andrei has mentioned that during his keynote but nothing has been ever done to improve the situation.
Jul 10 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 I can't blame Sonke or anyone else for not wanting to waste his 
 time on pushing more stuff upstream considering how miserable 
 contribution experience is right now.
This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that. Bye, bearophile
Jul 10 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
 Dicebot:

 I can't blame Sonke or anyone else for not wanting to waste 
 his time on pushing more stuff upstream considering how 
 miserable contribution experience is right now.
This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that. Bye, bearophile
No one but Walter / Andrei can do anything about it. Right now we are in weird situation when they call for "lieutenants" but are not ready to abandon decision power. It can't possibly work that way. No amount of volunteer effort will help when so many PR stall waiting for resolution comment from one of language "generals".
Jul 10 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 No one but Walter / Andrei can do anything about it. Right now 
 we are in weird situation when they call for "lieutenants" but 
 are not ready to abandon decision power. It can't possibly work 
 that way. No amount of volunteer effort will help when so many 
 PR stall waiting for resolution comment from one of language 
 "generals".
It seems an important topic. Pull reverts (like: https://github.com/D-Programming-Language/phobos/commit/e5f7f41d253aacc601be 4b5a1e4f24cd5ecfc32 ) aren't process failures, they should be normal parts of the dmd/Phobos development process. Even if 5-8% of the merges gets reverted, it's still OK. And now there is the cherry picking, so it's hard to pollute betas with bad patches. Bye, bearophile
Jul 10 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 July 2014 at 13:09:42 UTC, bearophile wrote:
 Dicebot:

 No one but Walter / Andrei can do anything about it. Right now 
 we are in weird situation when they call for "lieutenants" but 
 are not ready to abandon decision power. It can't possibly 
 work that way. No amount of volunteer effort will help when so 
 many PR stall waiting for resolution comment from one of 
 language "generals".
It seems an important topic. Pull reverts (like: https://github.com/D-Programming-Language/phobos/commit/e5f7f41d253aacc601be 4b5a1e4f24cd5ecfc32 ) aren't process failures, they should be normal parts of the dmd/Phobos development process. Even if 5-8% of the merges gets reverted, it's still OK. And now there is the cherry picking, so it's hard to pollute betas with bad patches. Bye, bearophile
Yes. An advantage of a structured formal release process is that it frees up development to make mistakes in the short term.
Jul 10 2014
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 July 2014 at 12:54:19 UTC, Dicebot wrote:
 On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
 Dicebot:

 I can't blame Sonke or anyone else for not wanting to waste 
 his time on pushing more stuff upstream considering how 
 miserable contribution experience is right now.
This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that. Bye, bearophile
No one but Walter / Andrei can do anything about it. Right now we are in weird situation when they call for "lieutenants" but are not ready to abandon decision power. It can't possibly work that way. No amount of volunteer effort will help when so many PR stall waiting for resolution comment from one of language "generals".
To be fair to Walter/Andrei, you need to be clear who your lieutenant is before you can delegate to them. Who has stepped up to take charge of concurrency in D?
Jul 10 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
 To be fair to Walter/Andrei, you need to be clear who your 
 lieutenant is before you can delegate to them.

 Who has stepped up to take charge of concurrency in D?
I think it should be other way around - announcing slot with listed responsibilities / decision power and asking for volunteers, same as it was done with release process "tzar" (kudos Andrew). Just "stepping up" is a no-op action without explicit delegation. Also I believe every such domain needs two persons in charge and not just one - for example, Sean Kelly is most suitable candidate for such role but who accept his PR then? :)
Jul 10 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 July 2014 at 14:14:20 UTC, Dicebot wrote:
 On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
 To be fair to Walter/Andrei, you need to be clear who your 
 lieutenant is before you can delegate to them.

 Who has stepped up to take charge of concurrency in D?
I think it should be other way around - announcing slot with listed responsibilities / decision power and asking for volunteers, same as it was done with release process "tzar" (kudos Andrew). Just "stepping up" is a no-op action without explicit delegation. Also I believe every such domain needs two persons in charge and not just one - for example, Sean Kelly is most suitable candidate for such role but who accept his PR then? :)
Walter & Andrei Would a list of subject areas that require delegation be a good idea to put on the wiki? A list of positions, both available and filled?
Jul 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 7:24 AM, John Colvin wrote:
 On Thursday, 10 July 2014 at 14:14:20 UTC, Dicebot wrote:
 On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
 To be fair to Walter/Andrei, you need to be clear who your lieutenant
 is before you can delegate to them.

 Who has stepped up to take charge of concurrency in D?
I think it should be other way around - announcing slot with listed responsibilities / decision power and asking for volunteers, same as it was done with release process "tzar" (kudos Andrew). Just "stepping up" is a no-op action without explicit delegation. Also I believe every such domain needs two persons in charge and not just one - for example, Sean Kelly is most suitable candidate for such role but who accept his PR then? :)
Walter & Andrei Would a list of subject areas that require delegation be a good idea to put on the wiki? A list of positions, both available and filled?
I think that's a good idea, I'll think of it. In the meantime there seems to be a want of even foot soldiers and corporals, which seems to be a good way to promote lieutenants. In the post I just sent I pointed out a number of good and absolutely trivial pull requests for https://github.com/D-Programming-Language/phobos that simply sit there for days and weeks. Andrei
Jul 10 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 5:54 AM, Dicebot wrote:
 On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
 Dicebot:

 I can't blame Sonke or anyone else for not wanting to waste his time
 on pushing more stuff upstream considering how miserable contribution
 experience is right now.
This was one of the causes of the creation of Tango and its fiasco, so better to not repeat that. Bye, bearophile
No one but Walter / Andrei can do anything about it. Right now we are in weird situation when they call for "lieutenants" but are not ready to abandon decision power.
In the military (where the metaphor has been drawn for) there are lieutenants and there's no abandonment of decision power. Of course I wouldn't push the simile too much.
 It can't possibly work that way. No amount of
 volunteer effort will help when so many PR stall waiting for resolution
 comment from one of language "generals".
I'll make a pass, but on the face of it I disagree. There's just lots and lots and lots of obviously good things that just don't get done until Walter or I do them. Last example I remember is video links for the DConf 2014 talks on dconf.org. The SMALLEST and OBVIOUSLY GOOD THING anyone could imagine. Someone on reddit mentioned we should put them there. Nobody in the community did anything about it until I posted the pull request for day 1 (http://goo.gl/9EUXv1) and Walter pulled it (http://goo.gl/O22dsa). In the meantime, everybody's busy arguing the minutia of logo redesign. The length (not existence) of that thread is a piece of evidence of what's wrong with our community. Looking at https://github.com/D-Programming-Language/phobos/pulls, I agree there are a few controversial pull requests that are explicitly waiting for me, such as https://github.com/D-Programming-Language/phobos/pull/1010. I'd need a fair amount of convincing that that's a frequent case. Looking at the second oldest pull request (https://github.com/D-Programming-Language/phobos/pull/1138) that's just a documentation pull, on which I myself last asked about status on March 15. Furthermore there are just a good amount of pull requests that have nothing to do with any leadership. E.g. https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Switching to newer pull requests, there are simple and obviously good pull requests that just sit there for anyone to pull. And that includes you, Dicebot, since a few seconds ago. Since you don't mince words when criticizing the leadership you may as well put your money where your mouth is. https://github.com/D-Programming-Language/phobos/pull/2300 for example is simple, obviously good, and could be pulled in a minute by any of our 24, pardon, 25 core pullers who has a basic understanding of trusted. Then there's stuff I have no expertise in such as https://github.com/D-Programming-Language/phobos/pull/2307. Not only I'm not on hook for that, I better not discuss and pull that and leave it to someone who knows curl better. Of course that doesn't undo the fact that Walter and I are on hook for a number of things. What I'm saying is I disagree with the allegation that "no amount of volunteer effort will help". From the looks of things, we're in dire need of volunteer effort. Andrei
Jul 10 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu 
wrote:
 Then there's stuff I have no expertise in such as 
 https://github.com/D-Programming-Language/phobos/pull/2307. Not 
 only I'm not on hook for that, I better not discuss and pull 
 that and leave it to someone who knows curl better.
I agree with most of what you have said (and definitely can be blamed guilty) but this situation was exactly what I had in mind for original rant. You don't feel that you are competent enough to judge that PR and everyone else (including those few who possibly can be proficient) does not feel authoritative enough make the decision. It is not your personal failure (and I apologize if my words sound like that) but general organizational problem. I believe calling for explicit domains of responsibility ( as opposed to just giving push access :'( ) is one way to address that. Quite likely there are better approaches but those are for someone else to propose.
Jul 10 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
Jul 10 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 July 2014 at 14:54:51 UTC, Dicebot wrote:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
I don't see why this would invalidate the licence: fork the branch that contains the request, rebase to fix any conflicts, make any extra commits needed, open a new pull request. It's really no different from merging the pull and then fixing it afterwards.
Jul 10 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 15:35:03 UTC, John Colvin wrote:
 On Thursday, 10 July 2014 at 14:54:51 UTC, Dicebot wrote:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
I don't see why this would invalidate the licence: fork the branch that contains the request, rebase to fix any conflicts, make any extra commits needed, open a new pull request. It's really no different from merging the pull and then fixing it afterwards.
So long as the author's name remains in place in the license blurb I think you're pretty much free to do whatever you want with the code. That's the beauty of the Boost license. It's as close to Public Domain as it seems possible to get given the vagaries of international law. I would *love* to have a good networking package in Phobos. It's D. It just happens to conflict a bit too much with my professional work for me to comfortably make any contribution without internal approval, and I don't see that happening unless we start using D and want to contribute back to the language. vibe.d exists now though, and maybe someone could tease it apart to get some portion of it in Phobos and leave the rest as a third-party extension? That's being actively developed, and is really quite nice, though perhaps not so general-purpose as std.net was intended to be. It seems that most of my active use of D these days is writing scripts to talk to our servers for various tasks. For the most part I just use libcurl for that and it's pretty okay, but for the things that don't talk HTTP... ugh.
Jul 10 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 7:54 AM, Dicebot wrote:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
That's totally on topic! I think it's fair game to take over pull requests of which authors did not respond to repeated pings. -- Andrei
Jul 10 2014
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 10 Jul 2014 08:50:12 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 7/10/14, 7:54 AM, Dicebot wrote:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
That's totally on topic! I think it's fair game to take over pull requests of which authors did not respond to repeated pings. -- Andrei
I agree, but it's probably a good idea to keep the author name in the git history. In git author/committer can be different, see http://stackoverflow.com/questions/18750808/difference-between-author-and-committer-in-git
Jul 10 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 8:50 AM, Andrei Alexandrescu wrote:
 On 7/10/14, 7:54 AM, Dicebot wrote:
 E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some apparently work that's just sitting there abandoned. Hm, slightly OT: is it considered widely acceptable to take over such pull requests by reopening rebased one with identical content? I presume Boost licensing implies so but not sure everyone else expects the same.
That's totally on topic! I think it's fair game to take over pull requests of which authors did not respond to repeated pings. -- Andrei
Yup. Just include a link to the old one in your reboot of it, so the original author gets credit/blame for their work, even if they've disappeared.
Jul 10 2014
prev sibling next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu 
wrote:
 Switching to newer pull requests, there are simple and 
 obviously good pull requests that just sit there for anyone to 
 pull.
This. I think pull requests tend to sit because people don't feel they have the authority to push the button, and all the author can do is ask. I know I should be a better shepherd of Druntime as well, and should have some actual free time in about another month where I hope to start catching up.
Jul 10 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu 
wrote:
 In the meantime, everybody's busy arguing the minutia of logo 
 redesign. The length (not existence) of that thread is a piece 
 of evidence of what's wrong with our community.
Actually, that thread is a good sign and a good source for community building. You know, people establishing boundaries and goals together rather than trying to figure out if it is worth contributing the vision of somebody else or adding to an existing patchwork which has a unclear direction. It was a small managable piece (the logo) so people felt like participating. It also was a ground where people can share their views on what-we-really-are-about on an abstract level.
 Of course that doesn't undo the fact that Walter and I are on 
 hook for a number of things. What I'm saying is I disagree with 
 the allegation that "no amount of volunteer effort will help". 
 From the looks of things, we're in dire need of volunteer 
 effort.
Motivation is a difficult sport, but it would help a lot if you just specced out the D2 language fully and plotted in the missing parts, without implementation, but with proofs of correctness. All this putting stuff in, then ripping it out is demotivating. (Why contribute if it will be ripped out at the next turn of events?) People with formal training (CS background) will favour elegance and correctness, which implies solid advance speccing… Without it, they are unlikely to contribute unless they have D in production or miss features which could make it possible for them to use D in production… There is too much pushing for breadth in the D community. What you need is depth, the depth of quality and polish. Possibly reducing the scopes and feature set, not extending it even more. Maybe you have to cut back on system programming and go for fast brute force lock-the-world GC without destructors, or maybe you have to favour system programming. But surely, the worst option is to not set a clear direction. To match up with the best-in-class in the web space you need a tight performant HTTP and SPDY implementation with support for all relevant content negotiation headers, solid caching handling, automatic compression, well working timeouts/load balancing, all the right hooks for rapid development, builtin Memcache support, a solid NOSQL abstraction, a transactional task queue and be tight on memory so you can run the service on cheap hosting. That would bring you to the basics of Go/App Engine… Then you have to be better… Kudos for vibe.d, but it won't really matter until it is better than the alternatives. Building WordPress on top of it won't matter, because creating WordPress is not difficult. The difficult part is building the WordPress community.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 8:51 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 but it would help a lot if you just specced out
 the D2 language fully and plotted in the missing parts, without implementation,
 but with proofs of correctness. All this putting stuff in, then ripping it out
 is demotivating. (Why contribute if it will be ripped out at the next turn of
 events?)
Again, you're asking Andrei and I to do all the work.
Jul 10 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 July 2014 at 18:46:08 UTC, Walter Bright wrote:
 Again, you're asking Andrei and I to do all the work.
Well, I could spec a draft, but it would be met with too much resistance based on what people have gotten used to (habits, for good or bad). Only you and Andrei can put force behind changes that will pry dangerous toys out of the hands of the habitants… So I think the more fruitful approach for me is find a minimal representation that can cover C, most of D2 and close follow ups, let's call them D++ or D--. That way you don't break most code and can do whole program analysis/optimization with proper safe validation… Seems to me that you can have many languages in the same build and do semantic analysis on the whole. Provided that the generated languages (after generics have been instantiated) are close in semantics, of course. That's the best I can come up with… Not what you are asking for, but what you are asking for will never make me happy ;-)
Jul 10 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 07:30:42AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 Looking at the second oldest pull request
 (https://github.com/D-Programming-Language/phobos/pull/1138) that's
 just a documentation pull, on which I myself last asked about status
 on March 15.
Sorry, I got busy and didn't have time to look at it. I just updated it per the latest comments; please review.
 Furthermore there are just a good amount of pull requests that have
 nothing to do with any leadership. E.g.
 https://github.com/D-Programming-Language/phobos/pull/1527 is some
 apparently work that's just sitting there abandoned.
Perhaps somebody should take over this pull (fork it or copy-n-paste, whatever). I haven't used std.net.curl since that last time, and likely won't be using it anytime soon because I find the API hard to use -- for my needs, using std.process to call wget/curl is good enough. So I'm probably not the best person to work on the API right now. And just for the record, I have no problem whatsoever with people taking over my PRs and submitting their own PRs with identical content. What's important is that the code gets in there somehow. [...]
 Of course that doesn't undo the fact that Walter and I are on hook for
 a number of things. What I'm saying is I disagree with the allegation
 that "no amount of volunteer effort will help". From the looks of
 things, we're in dire need of volunteer effort.
[...] Since we're on this topic, I wish somebody would review this PR: https://github.com/D-Programming-Language/phobos/pull/2276 There have been multiple usability bugs filed against cartesianProduct, and this PR addresses the most common use case (which is also the simplest to fix) in those complaints. Some of these bugs have been around for a while, and only recently have I found the time to actually do something about it... only to get ignored. Other than some comments from bearophile, I've seen no comments from anyone else, and it's been almost 2 weeks, so right now I don't even know what else to do. I suspect this is one of the problems (perceived or otherwise) with the current PR process. A lot of work is just sitting there without even an acknowledgement from a bystander, so to speak, and the few that do get some attention, after comments have been addressed, continue to sit there with no indication of whether the change is unacceptable, or uninteresting, or interesting but people are too busy to look at it, or what. Sometimes I just stare at the PR page day after day asking, is something missing? Do people expect any other changes? Are people too busy to even look at it? Even a casual remark as "I'll get around to this on the weekend (or next month, or, for that matter, next *year*)" would help bolster morale significantly. Letting things sit in limbo without so much as a comment, says, intentionally or not, that we just don't care, and that's very discouraging to potential contributors. Now I'm not saying this with any bitterness, and, having a full-time job myself plus countless other responsibilities with family, etc., I totally understand that sometimes people are just too busy to respond. Or sometimes a PR is just beyond your depth and you don't really want to get involved for fear of saying things or making decisions that you aren't qualified to make. But judging at the frequency of non-response to PRs, I'm starting to wonder if we, as a community, have bitten off a far bigger chunk than we can chew, in the sense that Phobos covers a huge scope of very different things, yet there aren't enough people interested / qualified in each specific area to be able to review / pull PRs directed at that area in a timely manner. Perhaps we're becoming the jack of all trades and master of one, so to speak? T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Jul 10 2014
next sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Thursday, 10 July 2014 at 16:55:34 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Since we're on this topic, I wish somebody would review this PR:

 	https://github.com/D-Programming-Language/phobos/pull/2276
I'm not familiar enough with algoFormat to say that I've "reviewed it." In retrospect, adding that as comment would have been better than silence.
 Some of these bugs have been
 around for a while, and only recently have I found the time to 
 actually
 do something about it... only to get ignored. Other than some 
 comments
 from bearophile, I've seen no comments from anyone else, and 
 it's been
 almost 2 weeks, so right now I don't even know what else to do.

 I suspect this is one of the problems (perceived or otherwise) 
 with the
 current PR process. A lot of work is just sitting there without 
 even an
 acknowledgement from a bystander, so to speak, and the few that 
 do get
 some attention, after comments have been addressed, continue to 
 sit
 there with no indication of whether the change is unacceptable, 
 or
 uninteresting, or interesting but people are too busy to look 
 at it, or
 what. Sometimes I just stare at the PR page day after day 
 asking, is
 something missing? Do people expect any other changes?  Are 
 people too
 busy to even look at it? Even a casual remark as "I'll get 
 around to
 this on the weekend (or next month, or, for that matter, next 
 *year*)"
 would help bolster morale significantly. Letting things sit in 
 limbo
 without so much as a comment, says, intentionally or not, that 
 we just
 don't care, and that's very discouraging to potential 
 contributors.
This is exactly the typical contributor experience.
 Now I'm not saying this with any bitterness, and, having a 
 full-time job
 myself plus countless other responsibilities with family, etc., 
 I
 totally understand that sometimes people are just too busy to 
 respond.
It's difficult to believe that everybody is too busy to review PRs yet have ample time to invest in the most futile of forum discussions.
Jul 10 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 16:55:34 UTC, H. S. Teoh via Digitalmars-d
[...]
I suspect this is one of the problems (perceived or otherwise) with
the current PR process. A lot of work is just sitting there without
even an acknowledgement from a bystander, so to speak, and the few
that do get some attention, after comments have been addressed,
continue to sit there with no indication of whether the change is
unacceptable, or uninteresting, or interesting but people are too
busy to look at it, or what. Sometimes I just stare at the PR page
day after day asking, is something missing? Do people expect any
other changes?  Are people too busy to even look at it? Even a casual
remark as "I'll get around to this on the weekend (or next month, or,
for that matter, next *year*)" would help bolster morale
significantly. Letting things sit in limbo without so much as a
comment, says, intentionally or not, that we just don't care, and
that's very discouraging to potential contributors.
This is exactly the typical contributor experience.
Which we must change if we're going to increase D adoption. Unfortunately, I don't see any good solution to this, except just hoping for more contributors to pick up different pieces of Phobos as their "passion" and become the "lieutenant" for that part of it. But that requires first of all that contributors are motivated to contribute, yet the current situation isn't encouraging them to join in. It's a vicious cycle, and I don't know how to break it.
Now I'm not saying this with any bitterness, and, having a full-time
job myself plus countless other responsibilities with family, etc., I
totally understand that sometimes people are just too busy to
respond.
It's difficult to believe that everybody is too busy to review PRs yet have ample time to invest in the most futile of forum discussions.
Well, that's just because futile forum discussions take almost no effort, while reviewing PRs requires the actual use of brain cells! ;-) As somebody once said, talk is cheap, and whining is actually free. Reviewing PRs, OTOH, requires one to actually sit down and look at real code and think over it. Not that it's a valid excuse, but this *is* a volunteer community, and people aren't going to do what they're asked to do, only what they're interested to do. T -- The richest man is not he who has the most, but he who needs the least.
Jul 10 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 18:25:56 UTC, H. S. Teoh via
Digitalmars-d wrote:
 On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via
 
 This is exactly the typical contributor experience.
Which we must change if we're going to increase D adoption. Unfortunately, I don't see any good solution to this, except just hoping for more contributors to pick up different pieces of Phobos as their "passion" and become the "lieutenant" for that part of it. But that requires first of all that contributors are motivated to contribute, yet the current situation isn't encouraging them to join in. It's a vicious cycle, and I don't know how to break it.
I think part of this will have to come from a policy change regarding pull requests. I propose that any pull request must either be merged or rejected within one month of submission. I'd rather see a request rejected with an explanation than for it to languish in revision hell for months or years while people slowly iterate on changes. It's better in my minds to submit a request, have it rejected with comments, fix and resubmit multiple times than to have pull requests just sitting in the queue forever with no one knowing what their status is.
Jul 10 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 06:32:06PM +0000, Sean Kelly via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 18:25:56 UTC, H. S. Teoh via
 Digitalmars-d wrote:
On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via
This is exactly the typical contributor experience.
Which we must change if we're going to increase D adoption. Unfortunately, I don't see any good solution to this, except just hoping for more contributors to pick up different pieces of Phobos as their "passion" and become the "lieutenant" for that part of it. But that requires first of all that contributors are motivated to contribute, yet the current situation isn't encouraging them to join in. It's a vicious cycle, and I don't know how to break it.
I think part of this will have to come from a policy change regarding pull requests. I propose that any pull request must either be merged or rejected within one month of submission. I'd rather see a request rejected with an explanation than for it to languish in revision hell for months or years while people slowly iterate on changes. It's better in my minds to submit a request, have it rejected with comments, fix and resubmit multiple times than to have pull requests just sitting in the queue forever with no one knowing what their status is.
That's a good start; I like that. Another thing that might help, is if we can somehow change the default sort order on the github PR page. Currently it's defaulted to newest first, but that's a horrible default order given our circumstances. A much better order is "least recently updated", so that the oldest, most ignored PRs will get attention first. Even if they are mostly ignored, at least every time somebody goes to that page they'll see it in passing, and perhaps decide one day to actually look into what it is. As opposed to the current situation of "out of sight, out of mind". T -- Любишь кататься - люби и саночки возить.
Jul 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 11:49 AM, H. S. Teoh via Digitalmars-d wrote:
 Another thing that might help, is if we can somehow change the default
 sort order on the github PR page. Currently it's defaulted to newest
 first, but that's a horrible default order given our circumstances. A
 much better order is "least recently updated", so that the oldest, most
 ignored PRs will get attention first. Even if they are mostly ignored,
 at least every time somebody goes to that page they'll see it in
 passing, and perhaps decide one day to actually look into what it is. As
 opposed to the current situation of "out of sight, out of mind".
I'd prefer "most recently commented on or updated". That way, the originator can post a ping causing it to bubble up to the top.
Jul 10 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 11:01 AM, safety0ff wrote:
 It's difficult to believe that everybody is too busy to review PRs yet
 have ample time to invest in the most futile of forum discussions.
Amen to that. Andrei
Jul 10 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 9:53 AM, H. S. Teoh via Digitalmars-d wrote:
 Since we're on this topic, I wish somebody would review this PR:

 	https://github.com/D-Programming-Language/phobos/pull/2276
I'll have a go. BTW, I had no idea quickfur was you. I know people like using pseudonyms on github, but the D community is large and it takes me a long time to connect in my brain which ng member is which github contributor. I.e. I wish y'all would use github accounts under your own name. It's not like there's anything on there that'll embarrass anyone if it goes on the front page of the nytimes :-) and nobody should be tempted to post such stuff.
Jul 10 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 11:50:57AM -0700, Walter Bright via Digitalmars-d wrote:
 On 7/10/2014 9:53 AM, H. S. Teoh via Digitalmars-d wrote:
Since we're on this topic, I wish somebody would review this PR:

	https://github.com/D-Programming-Language/phobos/pull/2276
I'll have a go.
Thanks!
 BTW, I had no idea quickfur was you. I know people like using
 pseudonyms on github, but the D community is large and it takes me a
 long time to connect in my brain which ng member is which github
 contributor.
 
 I.e. I wish y'all would use github accounts under your own name. It's
 not like there's anything on there that'll embarrass anyone if it goes
 on the front page of the nytimes :-) and nobody should be tempted to
 post such stuff.
I didn't exactly go out of my way to *hide* my real name, y'know -- it's right on my github profile in a prominent font if you'd only click on my pseudonym. ;-) Surely it's not *that* hard? T -- What are you when you run out of Monet? Baroque.
Jul 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 11:58 AM, H. S. Teoh via Digitalmars-d wrote:
 I didn't exactly go out of my way to *hide* my real name, y'know -- it's
 right on my github profile in a prominent font if you'd only click on my
 pseudonym.  ;-) Surely it's not *that* hard?
I know it isn't hard, but it's a pointless indirection and shouldn't be a virtual function :-)
Jul 10 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 5:54 AM, Dicebot wrote:
 No one but Walter / Andrei can do anything about it. Right now we are in weird
 situation when they call for "lieutenants" but are not ready to abandon
decision
 power. It can't possibly work that way. No amount of volunteer effort will help
 when so many PR stall waiting for resolution comment from one of language
 "generals".
Here are the teams with Pulling Power: https://github.com/orgs/D-Programming-Language/teams Team Phobos, for example, has 25 members. Including you!
Jul 13 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
 On 7/10/2014 5:54 AM, Dicebot wrote:
 No one but Walter / Andrei can do anything about it. Right now 
 we are in weird
 situation when they call for "lieutenants" but are not ready 
 to abandon decision
 power. It can't possibly work that way. No amount of volunteer 
 effort will help
 when so many PR stall waiting for resolution comment from one 
 of language
 "generals".
Here are the teams with Pulling Power: https://github.com/orgs/D-Programming-Language/teams Team Phobos, for example, has 25 members. Including you!
You do realize that Andrei has added me to that list exactly after this message I have posted to shut me up? :grumpy:
Jul 13 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2014 3:47 AM, Dicebot wrote:
 On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
 On 7/10/2014 5:54 AM, Dicebot wrote:
 No one but Walter / Andrei can do anything about it. Right now we are in weird
 situation when they call for "lieutenants" but are not ready to abandon
decision
 power. It can't possibly work that way. No amount of volunteer effort will help
 when so many PR stall waiting for resolution comment from one of language
 "generals".
Here are the teams with Pulling Power: https://github.com/orgs/D-Programming-Language/teams Team Phobos, for example, has 25 members. Including you!
You do realize that Andrei has added me to that list exactly after this message I have posted to shut me up? :grumpy:
No, I didn't realize that, thanks for letting me know. But there are still 24 other members, which is a lot more than just Andrei and I.
Jul 13 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
 On 7/10/2014 5:54 AM, Dicebot wrote:
 No one but Walter / Andrei can do anything about it. Right now 
 we are in weird
 situation when they call for "lieutenants" but are not ready 
 to abandon decision
 power. It can't possibly work that way. No amount of volunteer 
 effort will help
 when so many PR stall waiting for resolution comment from one 
 of language
 "generals".
Here are the teams with Pulling Power: https://github.com/orgs/D-Programming-Language/teams Team Phobos, for example, has 25 members. Including you!
Also I was not speaking originally about "all good" pull requests just waiting to be merged but about stuff that hits some controversial language/Phobos parts and requires some decision if it can be accepted at all. Pretty much no one but you can make such judgement even if there are many people with merge rights. It is probably more of an issue for DMD than Phobos because almost any enhancement for language needs to get your approval or go away.
Jul 13 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2014 4:05 AM, Dicebot wrote:
 Also I was not speaking originally about "all good" pull requests just waiting
 to be merged but about stuff that hits some controversial language/Phobos parts
 and requires some decision if it can be accepted at all. Pretty much no one but
 you can make such judgement even if there are many people with merge rights.

 It is probably more of an issue for DMD than Phobos because almost any
 enhancement for language needs to get your approval or go away.
That is true, but Andrei and I also rely heavily on feedback from you guys about those issues. For example, Sean's std.concurrency pull. I gotta rely on reviews from you fellows, because I am hardly an expert on best practices for concurrency programming. In fact I'm rather a newbie at it.
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 13 July 2014 at 18:20:12 UTC, Walter Bright wrote:
 On 7/13/2014 4:05 AM, Dicebot wrote:
 Also I was not speaking originally about "all good" pull 
 requests just waiting
 to be merged but about stuff that hits some controversial 
 language/Phobos parts
 and requires some decision if it can be accepted at all. 
 Pretty much no one but
 you can make such judgement even if there are many people with 
 merge rights.

 It is probably more of an issue for DMD than Phobos because 
 almost any
 enhancement for language needs to get your approval or go away.
That is true, but Andrei and I also rely heavily on feedback from you guys about those issues. For example, Sean's std.concurrency pull. I gotta rely on reviews from you fellows, because I am hardly an expert on best practices for concurrency programming. In fact I'm rather a newbie at it.
I will keep an eye std.concurrency but I what should I do to convince you say a word or two about DMD PR that makes some language change? :)
Jul 14 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2014 9:56 AM, Dicebot wrote:
 I will keep an eye std.concurrency but I what should I do to convince you say a
 word or two about DMD PR that makes some language change? :)
I still believe that Andrei & I need to approve language change PRs. These can be very disruptive and not easily reverted if they aren't right. That said, we still strongly rely on feedback on these from the community. For example, https://issues.dlang.org/show_bug.cgi?id=11946
Jul 14 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
 On 7/14/2014 9:56 AM, Dicebot wrote:
 I will keep an eye std.concurrency but I what should I do to 
 convince you say a
 word or two about DMD PR that makes some language change? :)
I still believe that Andrei & I need to approve language change PRs. These can be very disruptive and not easily reverted if they aren't right. That said, we still strongly rely on feedback on these from the community. For example, https://issues.dlang.org/show_bug.cgi?id=11946
I mean something like this : https://github.com/D-Programming-Language/dmd/pull/3651 - change that was implemented, generally approved in NG discussion, adjusted to all review comments etc but still doesn't not have even single comment from you or Andrei if it is even has chance for being accepted. Just a short "Thinking, not sure" is much less discouraging than no comments at all.
Jul 14 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/14/14, 12:10 PM, Dicebot wrote:
 On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
 On 7/14/2014 9:56 AM, Dicebot wrote:
 I will keep an eye std.concurrency but I what should I do to convince
 you say a
 word or two about DMD PR that makes some language change? :)
I still believe that Andrei & I need to approve language change PRs. These can be very disruptive and not easily reverted if they aren't right. That said, we still strongly rely on feedback on these from the community. For example, https://issues.dlang.org/show_bug.cgi?id=11946
I mean something like this : https://github.com/D-Programming-Language/dmd/pull/3651 - change that was implemented, generally approved in NG discussion, adjusted to all review comments etc but still doesn't not have even single comment from you or Andrei if it is even has chance for being accepted. Just a short "Thinking, not sure" is much less discouraging than no comments at all.
Good example. Let me look into it! -- Andrei
Jul 14 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2014 12:10 PM, Dicebot wrote:
 On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
 For example,

   https://issues.dlang.org/show_bug.cgi?id=11946
I mean something like this : https://github.com/D-Programming-Language/dmd/pull/3651 - change that was implemented, generally approved in NG discussion, adjusted to all review comments etc but still doesn't not have even single comment from you or Andrei if it is even has chance for being accepted. Just a short "Thinking, not sure" is much less discouraging than no comments at all.
At the moment my focus is to get 2.066 out. If I don't, it'll just drift on and never happen. 11946 is one of the problem areas.
Jul 14 2014
prev sibling next sibling parent "Puming" <zhaopuming gmail.com> writes:
On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
 On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
 Are there any tutorials or blog posts out there demonstrating 
 how to use this? I think posts along the lines of "This is a 
 CSP/message passing program in Go/Erlang. This is the same 
 program translated into D; look how concise and faster it is!" 
 could attract a lot of interest.
There are no detailed blog posts and I believe only few developers are really well proficient with this vibe.d functionality. Some relevant docs: http://vibed.org/api/vibe.core.core/ http://vibed.org/api/vibe.core.concurrency/ http://vibed.org/api/vibe.core.task/
 Reading the code in the pull request [1], for instance, makes 
 me wonder how to tell if `spawn()` is spawning a thread or a 
 fibre. Can a tid refer to a fibre? If so, why's it called a 
 thread ID, and how do I tell if a particular tid refers to a 
 thread or fibre? It would be great to have these kinds of 
 questions answered in an easily available reference (for 
 instance, the documentation for std.concurrency, which 
 currently doesn't even mention fibres or vibe.d).

 1. https://github.com/D-Programming-Language/phobos/pull/1910
Problem is that this is most simple PR to simply add message-passing support for fibers. Adding some advanced schedulers with worker thread pool can be expected to be done on top but.. This small PR has been rotting there for ages with pretty much zero attention but from few interested persons. I can't blame Sonke or anyone else for not wanting to waste his time on pushing more stuff upstream considering how miserable contribution experience is right now. We can't really expect anything else to improve why it stays that bad - Andrei has mentioned that during his keynote but nothing has been ever done to improve the situation.
Scala has also a history of three implementations of actor system, until akka is merged into official support (with Akka's arthur Jonas Bonér becoming CTO of Typesafe). In vibe.d's case I think first people don't really know that there is a good fiber based actor system already in vibe.d, for that I think it would benefit by separating out to be a standalone library, then add more functionalities like location transparency of actors in akka. Otherwise people would only recognize vibe.d as a networking lib, with no intent to look for actors there.
Jul 10 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
 Problem is that this is most simple PR to simply add 
 message-passing support for fibers. Adding some advanced 
 schedulers with worker thread pool can be expected to be done 
 on top but.. This small PR has been rotting there for ages with 
 pretty much zero attention but from few interested persons.
Yep. It's been gathering dust but for the occasional request to rebase the code. A better scheduler can be added, but I think that should follow this pull request's addition to Phobos. I don't want to block the infrastructure from acceptance because people have issues with a complicated scheduler that happened to be bundled with it. Though as it is, one of the pull requests I created for Druntime for a Facebook request has sat for months, presumably because of a request regarding a documentation formatting change that I overlooked. And I know I'm not alone. Robert's struggle with getting std.logger accepted is the stuff told to children around the campfire so they don't venture out into the dark.
Jul 10 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the stuff told to
 children around the campfire so they don't venture out into the dark.
Actually we use his logger at Facebook quite extensively (and happily). -- Andrei
Jul 10 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu 
wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the 
 stuff told to
 children around the campfire so they don't venture out into 
 the dark.
Actually we use his logger at Facebook quite extensively (and happily). -- Andrei
And I still waiting for him to call for next formal review / voting round ;)
Jul 10 2014
parent Robert Schadek via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 07/10/2014 05:59 PM, Dicebot via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the stuff told to
 children around the campfire so they don't venture out into the dark.
Actually we use his logger at Facebook quite extensively (and happily). -- Andrei
And I still waiting for him to call for next formal review / voting round ;)
please, lets get cracking
Jul 10 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu 
wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the 
 stuff told to
 children around the campfire so they don't venture out into 
 the dark.
Actually we use his logger at Facebook quite extensively (and happily). -- Andrei
Yep, it's good! But still not in Phobos despite his efforts. At this point I honestly don't know what the blocker is either. Maybe just inertia.
Jul 10 2014
parent reply Robert Schadek via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 07/10/2014 06:05 PM, Sean Kelly via Digitalmars-d wrote:
 On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu wrote:
 On 7/10/14, 8:29 AM, Sean Kelly wrote:
 Robert's struggle with getting std.logger accepted is the stuff told to
 children around the campfire so they don't venture out into the dark.
Actually we use his logger at Facebook quite extensively (and happily). -- Andrei
Yep, it's good! But still not in Phobos despite his efforts. At this point I honestly don't know what the blocker is either. Maybe just inertia.
It is not just the logger. I have multiple PRs who addressed all the critics, but are still getting nowhere it seams. I find myself rebasing from time to time just to get an autotester run to see if it still merges and performs. I know this is a bit OT and personal, but could somebody please merge indexOfNeither aka indexOfNone. I just hate to copy this function from one personal project to the next.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 12:57 PM, Robert Schadek via Digitalmars-d wrote:
 I know this is a bit OT and personal, but could somebody please merge
 indexOfNeither aka indexOfNone. I just hate to copy this function from
 one personal project to the next.
I don't know the PR link nor do I know what pseudonym you use on github, so please help! I reiterate my complaint that people use "virtual functions" for their github handles. There's no reason to. Who knows that 9il is actually Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out! Take a look at the contributor list: https://github.com/D-Programming-Language/phobos/pulls I'm sure y'all know your own handles, but how many of the others do you know who they are?
Jul 10 2014
next sibling parent reply Robert Schadek via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 07/10/2014 10:31 PM, Walter Bright via Digitalmars-d wrote:
 On 7/10/2014 12:57 PM, Robert Schadek via Digitalmars-d wrote:
 I know this is a bit OT and personal, but could somebody please merge
 indexOfNeither aka indexOfNone. I just hate to copy this function from
 one personal project to the next.
I don't know the PR link nor do I know what pseudonym you use on github, so please help!
https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither https://github.com/D-Programming-Language/phobos/pull/2072 getoptX
 I reiterate my complaint that people use "virtual functions" for their
 github handles. There's no reason to. Who knows that 9il is actually
 Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out!
burner
 Take a look at the contributor list:

 https://github.com/D-Programming-Language/phobos/pulls

 I'm sure y'all know your own handles, but how many of the others do
 you know who they are?
I'm starting to know faces to the usernames, but yes it is not optimal
Jul 10 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 1:49 PM, Robert Schadek via Digitalmars-d wrote:
 On 07/10/2014 10:31 PM, Walter Bright via Digitalmars-d wrote:
 On 7/10/2014 12:57 PM, Robert Schadek via Digitalmars-d wrote:
 I know this is a bit OT and personal, but could somebody please merge
 indexOfNeither aka indexOfNone. I just hate to copy this function from
 one personal project to the next.
I don't know the PR link nor do I know what pseudonym you use on github, so please help!
https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither https://github.com/D-Programming-Language/phobos/pull/2072 getoptX
 I reiterate my complaint that people use "virtual functions" for their
 github handles. There's no reason to. Who knows that 9il is actually
 Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out!
burner
Of course. "burner" is "robert" after you replace a few letters and anagram everything :o). I think we need to have a wiki.dlang.org page with MVPs listing a table with names and their github handles. There, it has reached my consciousness. Lieutenant responsible with the wiki, please take that over... it's an order... anyone?... hello?... Andrei
Jul 10 2014
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 10 July 2014 at 21:06:12 UTC, Andrei Alexandrescu 
wrote:
 I think we need to have a wiki.dlang.org page with MVPs listing 
 a table with names and their github handles. There, it has 
 reached my consciousness. Lieutenant responsible with the wiki, 
 please take that over... it's an order... anyone?... hello?...


 Andrei
Does the lieutenant for the wiki know who he is? If we can promote ourselves to lieutenant, I'm now in charge of the language spec.
Jul 10 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 21:09:00 UTC, Brian Schott wrote:
 Does the lieutenant for the wiki know who he is?

 If we can promote ourselves to lieutenant, I'm now in charge of 
 the language spec.
lieutenants are not usually elected but you have my vote anyway ;)
Jul 10 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 2:08 PM, Brian Schott wrote:
 On Thursday, 10 July 2014 at 21:06:12 UTC, Andrei Alexandrescu wrote:
 I think we need to have a wiki.dlang.org page with MVPs listing a
 table with names and their github handles. There, it has reached my
 consciousness. Lieutenant responsible with the wiki, please take that
 over... it's an order... anyone?... hello?...


 Andrei
Does the lieutenant for the wiki know who he is? If we can promote ourselves to lieutenant, I'm now in charge of the language spec.
You asked for it. http://wiki.dlang.org/MVPs Now go edit the page to add your github ID. Then go to the supplies area to get your camo gear and epaulets. Andrei
Jul 10 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 02:21:54PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 http://wiki.dlang.org/MVPs
[...] Should this be merged with http://wiki.dlang.org/People ? T -- Obviously, some things aren't very obvious.
Jul 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 2:27 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Jul 10, 2014 at 02:21:54PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 [...]
 http://wiki.dlang.org/MVPs
[...] Should this be merged with http://wiki.dlang.org/People ?
Yah, let's go with People. Thanks! -- Andrei
Jul 10 2014
parent "Mike" <none none.com> writes:
On Friday, 11 July 2014 at 01:09:38 UTC, Andrei Alexandrescu 
wrote:
 On 7/10/14, 2:27 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Jul 10, 2014 at 02:21:54PM -0700, Andrei Alexandrescu 
 via Digitalmars-d wrote:
 [...]
 http://wiki.dlang.org/MVPs
[...] Should this be merged with http://wiki.dlang.org/People ?
Yah, let's go with People. Thanks! -- Andrei
Done. http://wiki.dlang.org/?title=MVPs&redirect=no
Jul 10 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 02:06:11PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 7/10/14, 1:49 PM, Robert Schadek via Digitalmars-d wrote:
On 07/10/2014 10:31 PM, Walter Bright via Digitalmars-d wrote:
[...]
I reiterate my complaint that people use "virtual functions" for
their github handles. There's no reason to. Who knows that 9il is
actually Ilya Yaroshenko? Took me 3 virtual function dispatches to
find that out!
burner
Of course. "burner" is "robert" after you replace a few letters and anagram everything :o). I think we need to have a wiki.dlang.org page with MVPs listing a table with names and their github handles. There, it has reached my consciousness. Lieutenant responsible with the wiki, please take that over... it's an order... anyone?... hello?...
[...] Um... guys?? It's a *wiki*... we don't need lieutenants for that!! http://wiki.dlang.org/People P.S. I started a table of mappings based on a 5-minute gleaning of the Phobos PR page... please add your name to it and/or correct any mistakes I may have made. C'mon, people, this seriously isn't *that* hard!! T -- People tell me that I'm skeptical, but I don't believe it.
Jul 10 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
 I'm starting to know faces to the usernames, but yes it is not optimal
I would also like if people used their own face for the avatar, making it easier for me to connect faces with names at Dconf, but I suppose that is asking too much :-) Keep in mind, though, that the government already knows who you are anyway. If you want to be off the grid, posting to github is the wrong way to go about that.
Jul 10 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
 https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither
I want to defer this to Andrei.
 https://github.com/D-Programming-Language/phobos/pull/2072 getoptX
Looks nice. Auto-merged toggled on.
Jul 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 2:25 PM, Walter Bright wrote:
 On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
 https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither
I want to defer this to Andrei.
Merged. -- Andrei
Jul 10 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 11 July 2014 at 01:08:59 UTC, Andrei Alexandrescu 
wrote:
 On 7/10/14, 2:25 PM, Walter Bright wrote:
 On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
 https://github.com/D-Programming-Language/phobos/pull/1977 
 indexOfNeither
I want to defer this to Andrei.
Merged. -- Andrei
For any other aspiring lieutenants out there, this[0] has been sitting around for 5 months now. [0]https://github.com/D-Programming-Language/phobos/pull/1965#issuecomment-40362545
Jul 10 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jul 11, 2014 at 01:14:37AM +0000, Meta via Digitalmars-d wrote:
 On Friday, 11 July 2014 at 01:08:59 UTC, Andrei Alexandrescu wrote:
On 7/10/14, 2:25 PM, Walter Bright wrote:
On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
https://github.com/D-Programming-Language/phobos/pull/1977
indexOfNeither
I want to defer this to Andrei.
Merged. -- Andrei
For any other aspiring lieutenants out there, this[0] has been sitting around for 5 months now. [0]https://github.com/D-Programming-Language/phobos/pull/1965#issuecomment-40362545
Not that I'm a lieutenant or anything, but I did add some comments. T -- Some days you win; most days you lose.
Jul 11 2014
prev sibling next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 20:31:53 UTC, Walter Bright wrote:
 I reiterate my complaint that people use "virtual functions" 
 for their github handles. There's no reason to.
Collisions? "Walter Bright" might be reasonably uncommon, but I have to compete with one of the most famous cyclists of all time! :-) To compensate, I use the same "virtual function" literally everywhere. Same icon photo too. Take that, cyberstalkers!
Jul 10 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 10 July 2014 at 21:40:15 UTC, Sean Kelly wrote:
 :-)  To compensate, I use the same "virtual function" literally
 everywhere.  Same icon photo too.
That's Go…
Jul 10 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 21:46:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 10 July 2014 at 21:40:15 UTC, Sean Kelly wrote:
 :-)  To compensate, I use the same "virtual function" literally
 everywhere.  Same icon photo too.
That's Go…
And Go is awesome. I could change it to my face, but since that's on gravitar it would show up all over the place and I don't really want that.
Jul 11 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 2:40 PM, Sean Kelly wrote:
 Collisions?  "Walter Bright" might be reasonably uncommon, but I
 have to compete with one of the most famous cyclists of all time!
 :-)  To compensate, I use the same "virtual function" literally
 everywhere.  Same icon photo too.  Take that, cyberstalkers!
Heck, use "TheRealSeanKelly", or "ComplexMathSeanKelly" or "SKelly" or "NotSeanPenn" :-)
Jul 10 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 10/07/14 22:31, Walter Bright wrote:

 I don't know the PR link nor do I know what pseudonym you use on github,
 so please help!

 I reiterate my complaint that people use "virtual functions" for their
 github handles. There's no reason to. Who knows that 9il is actually
 Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out!
Talking about Github pseudonyms. I think it's very confusing that Hara Kenji is using a different author for his commits than his Github pseudonym. He commits as "k-hara", which doesn't exist on Github. But his Github pseudonym is "9rnsr". -- /Jacob Carlborg
Jul 11 2014
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 10 July 2014 at 20:31:53 UTC, Walter Bright wrote:
 I reiterate my complaint that people use "virtual functions" 
 for their github handles. There's no reason to. Who knows that 
 9il is actually Ilya Yaroshenko? Took me 3 virtual function 
 dispatches to find that out!
So, final by default in D? ;) -Wyatt
Jul 11 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 8:29 AM, Sean Kelly wrote:
 And I
 know I'm not alone. Robert's struggle with getting std.logger accepted is the
 stuff told to children around the campfire so they don't venture out into the
dark.
If it makes you feel better, it happens to me too. Everyone assumes someone else is responsible for pulling, and the end result is nothing happens. For example, this one: https://github.com/D-Programming-Language/dmd/pull/3613
Jul 10 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 11:39 AM, Walter Bright wrote:
 On 7/10/2014 8:29 AM, Sean Kelly wrote:
 And I
 know I'm not alone. Robert's struggle with getting std.logger accepted
 is the
 stuff told to children around the campfire so they don't venture out
 into the dark.
If it makes you feel better, it happens to me too. Everyone assumes someone else is responsible for pulling, and the end result is nothing happens. For example, this one: https://github.com/D-Programming-Language/dmd/pull/3613
Well I just pulled that. -- Andrei
Jul 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 11:46 AM, Andrei Alexandrescu wrote:
 On 7/10/14, 11:39 AM, Walter Bright wrote:
 On 7/10/2014 8:29 AM, Sean Kelly wrote:
 And I
 know I'm not alone. Robert's struggle with getting std.logger accepted
 is the
 stuff told to children around the campfire so they don't venture out
 into the dark.
If it makes you feel better, it happens to me too. Everyone assumes someone else is responsible for pulling, and the end result is nothing happens. For example, this one: https://github.com/D-Programming-Language/dmd/pull/3613
Well I just pulled that. -- Andrei
Whatever it takes to get it pulled! :-) Tanks!
Jul 10 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 18:39:48 UTC, Walter Bright wrote:
 On 7/10/2014 8:29 AM, Sean Kelly wrote:
 And I
 know I'm not alone. Robert's struggle with getting std.logger 
 accepted is the
 stuff told to children around the campfire so they don't 
 venture out into the dark.
If it makes you feel better, it happens to me too. Everyone assumes someone else is responsible for pulling, and the end result is nothing happens. For example, this one: https://github.com/D-Programming-Language/dmd/pull/3613
I expect it happens to you even more often given your status. With the one month limit on pending pull requests I proposed though, maybe the author of a pull request could simply ask for comments when that time is up and if there are none he just pulls it himself. Worst case the pull could be reverted later.
Jul 10 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
 Reading the code in the pull request [1], for instance, makes 
 me wonder how to tell if `spawn()` is spawning a thread or a 
 fibre. Can a tid refer to a fibre? If so, why's it called a 
 thread ID, and how do I tell if a particular tid refers to a 
 thread or fibre? It would be great to have these kinds of 
 questions answered in an easily available reference (for 
 instance, the documentation for std.concurrency, which 
 currently doesn't even mention fibres or vibe.d).
That was a deliberate design decision--you're not supposed to know, or care, what it's spawning. This also allows up to change the scheduling algorithm without affecting user code. That said, because statics are thread-local by default, and because implementing fiber-local storage in a C-compatible language would be difficult, the scheduler is user-configurable. So there is some visibility into this, just not as a part of the normal spawn/send/receive flow.
Jul 10 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 1:58 PM, Sean Kelly wrote:
 we're pretty close in D once my Scheduler pull request is
 accepted.
I couldn't find it. Can you please add the link to the PR to: https://issues.dlang.org/show_bug.cgi?id=13086 ?
Jul 09 2014
parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 9 July 2014 at 22:55:19 UTC, Walter Bright wrote:
 On 7/9/2014 1:58 PM, Sean Kelly wrote:
 we're pretty close in D once my Scheduler pull request is
 accepted.
I couldn't find it. Can you please add the link to the PR to: https://issues.dlang.org/show_bug.cgi?id=13086 ?
https://github.com/D-Programming-Language/phobos/pull/1910
Jul 09 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
 Yes, I mean transitive, and understand what that implies.
I am positively shocked :)
 I have started work on porting the CDGC to D2, have compilable 
 version (that was
 easy thanks to earlier Sean work) but updating implementation 
 to match new
 druntime and pass tests will take quite some time.
Is CDGC's Luca's earlier work on concurrent GC?
Yes.
 I'd state it differently: "Marketing fuss about goroutines is 
 the killer feature
 of Go" :) It does not have any fundamental advantage over 
 existing actor model
 and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.
Who are "they"? I don't know any serious developer who praises goroutines if he was not a CSP fan before. I forsee that it will make no impact for D because we simply don't have resources to advertise it as killing feature (on a same scale Go did). Well, of course, if someone wants to waste his time on this - no objections from my side :)
 I don't know where it comes from but non-nullable reference 
 type has ZERO value
 if it is not the default one.
Making it the default is impossible for D. However, class _C { ... } alias NotNull!_C C; is entirely practical. It's not unlike the common C practice: typedef struct S { ... } S; to bring S out of the tag name space.
You are totally missing the point if you consider this even comparable replacement. Reason why non-nullable types are awesome because you are 100% sure compiler will force you to handle null cases and if program compiles it is guaranteed to be safe in that regard. What you propose makes hardly any difference.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 3:34 AM, Dicebot wrote:
 On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
 Is CDGC's Luca's earlier work on concurrent GC?
Yes.
Great!
 I'd state it differently: "Marketing fuss about goroutines is the killer
feature
 of Go" :) It does not have any fundamental advantage over existing actor model
 and I doubt it will matter _that_ much.
Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature.
Who are "they"?
I've heard it multiple times from people I trust. Sorry I can't be more specific.
 I don't know any serious developer who praises goroutines if he
 was not a CSP fan before. I forsee that it will make no impact for D because we
 simply don't have resources to advertise it as killing feature (on a same scale
 Go did).
Will it be a killer feature for D? No. But it is a valuable feature, and it looks to me like we can implement it without great effort, and without any language changes. If it can stop a major client from saying "we're going to use Go instead of D because of this" then it is worth it.
 You are totally missing the point if you consider this even comparable
 replacement. Reason why non-nullable types are awesome because you are 100%
sure
 compiler will force you to handle null cases and if program compiles it is
 guaranteed to be safe in that regard. What you propose makes hardly any
difference.
I'll risk annoying everyone by repeating at this point "what do you propose". Making non-null pointers the default is going to break every D program and so is not acceptable.
Jul 10 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 18:18:54 UTC, Walter Bright wrote:
 You are totally missing the point if you consider this even 
 comparable
 replacement. Reason why non-nullable types are awesome because 
 you are 100% sure
 compiler will force you to handle null cases and if program 
 compiles it is
 guaranteed to be safe in that regard. What you propose makes 
 hardly any difference.
I'll risk annoying everyone by repeating at this point "what do you propose". Making non-null pointers the default is going to break every D program and so is not acceptable.
Unfortunately I can only propose to do nothing and abandon this idea for any foreseeable future. It is one of sinkholes which consume lot of discussion time but all good solutions are unacceptable and all acceptable solutions are not practical. One possible compromise is to define a DScanner rule to assume all normal pointers/references non-nullable by convention and enforce it for Phobos . Don't know how realistic it can be though, most likely not at all.
Jul 10 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape 
 analysis, too.
IMO this is not good, because it should be applicable for pointers, classes and slices, too (and structs containing any of them, of course). If you use `ref` with these, an extra layer of indirection is introduced, which also changes the semantics, e.g. for non-const pointers the original pointer can suddenly be overwritten. `scope` is much better suited for borrowing, because it's orthogonal to `ref`.
 1. Ref Counting

 I believe that ARC is a pipe dream for D, as we've discussed 
 extensively here. But a ref counted object should work, and 
 would be very attractive, much like C++'s shared_ptr<T>.


 2. Unique References

 unique_ptr<T> is another big success for C++. 2.066 has already 
 made big strides in inferring uniqueness of expressions, but it 
 doesn't go so far as creating a Unique!T type.
std.type.Unique needs to be fleshed out, or a different type created (`Owned`?). The current `Unique` accepts only pointers and classes, but should really accept anything, as with borrowing. Desirable features include: * explicit or implicit move-semantics * a way to remove uniqueness (e.g. after sending a value to a different thread, it no longer needs to be Unique) * compiler support for verifying that the value it's constructed from _is_ actually unique * deterministic destruction * allocator support (because of the previous point) * usable inside aggregates * applicable to any type; a move overwrites the rhs with the type's init value Borrowing can elegantly solve many of the problems with Unique and RC: * Unique and RefCounted should be implicitly borrowable (opBorrow?) * library routines pervasively take their inputs as `scope`; no need to provide different overloads for Unique, RefCounted, normal values, or even user-implemented wrappers => abstracts away the implementation details while retaining safety
Jul 09 2014
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 9 July 2014 at 13:06:06 UTC, Marc Schütz wrote:
 std.type.Unique needs to be fleshed out, or a different type 
 created (`Owned`?).
There is an `Isolated` in vibe.d which is more tuned for usage with std.concurrency (its vibe.d fork to be specific)
Jul 09 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/08/2014 11:22 PM, Walter Bright wrote:
 ...

 3. 'ref' means 'borrowed', to use Rust's terminology

 We're almost there with this. This means better escape analysis, too.
 ...
What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 7:37 AM, Timon Gehr wrote:
 On 07/08/2014 11:22 PM, Walter Bright wrote:
 3. 'ref' means 'borrowed', to use Rust's terminology
 We're almost there with this. This means better escape analysis, too.
What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?
'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored, and one cannot take the address of a ref'd variable in safe code.
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Rationale?
Jul 09 2014
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/09/2014 09:50 PM, Walter Bright wrote:
 On 7/9/2014 7:37 AM, Timon Gehr wrote:
 On 07/08/2014 11:22 PM, Walter Bright wrote:
 3. 'ref' means 'borrowed', to use Rust's terminology
 We're almost there with this. This means better escape analysis, too.
What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?
'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored,
Borrowed pointers can be stored in data structures and they can be reassigned.
 and one cannot take the address of a ref'd variable in  safe code.
 ...
Borrowed should also be enforced in system code by default. Also, how do I borrow a class reference?
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Rationale?
null
Jul 09 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 5:24 PM, Timon Gehr wrote:
 On 07/09/2014 09:50 PM, Walter Bright wrote:
 On 7/9/2014 7:37 AM, Timon Gehr wrote:
 On 07/08/2014 11:22 PM, Walter Bright wrote:
 3. 'ref' means 'borrowed', to use Rust's terminology
 We're almost there with this. This means better escape analysis, too.
What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?
'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored,
Borrowed pointers can be stored in data structures and they can be reassigned.
My purpose in posting this is not "I have a design". I don't have a design. A design needs to be created: 1. assess where we are 2. decide where we want to be 3. have a design and a plan that gets there There's no law that says D refs must be exactly like Rust borrowed. We can come up with a design that works best for D. D != Rust. Do you have a design in mind?
 and one cannot take the address of a ref'd variable in  safe code.
 ...
Borrowed should also be enforced in system code by default. Also, how do I borrow a class reference?
Address that in the design.
 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Rationale?
null
??
Jul 09 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2014 02:39 AM, Walter Bright wrote:
 On 7/9/2014 5:24 PM, Timon Gehr wrote:
 On 07/09/2014 09:50 PM, Walter Bright wrote:
 On 7/9/2014 7:37 AM, Timon Gehr wrote:
 On 07/08/2014 11:22 PM, Walter Bright wrote:
 3. 'ref' means 'borrowed', to use Rust's terminology
 We're almost there with this. This means better escape analysis, too.
What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?
'ref' is already used conventionally in such a manner as implying it is borrowed. 'ref' pointers cannot be stored,
Borrowed pointers can be stored in data structures and they can be reassigned.
My purpose in posting this is not "I have a design". I don't have a design. A design needs to be created: 1. assess where we are
I think we are basically nowhere. Borrowing is about controlling lifetimes.
 2. decide where we want to be
I don't know, but I assume it would have to be competitive with what Rust provides.
 3. have a design and a plan that gets there

 There's no law that says D refs must be exactly like Rust borrowed. We
 can come up with a design that works best for D. D != Rust. Do you have
 a design in mind?
 ...
Roughly, but not with 'ref'. It is also an issue of syntax at this point. I think we should get at least the basics fixed there before talking in-depth about semantics. (In any case, I still have one DIP pending in an unacceptable state that I couldn't find the time to write down properly yet.) Fundamentally, we need syntax for (examples provided for illustration, those are not proposals): - Parametric polymorphism Eg.: void foo[A](int x){ ... } - Lifetime parameters. (it's more future-proof if they are not introduced by simple identifiers.) Eg.: void foo[lifetime lt](int x){ ... } - Attaching a lifetime to a pointer, class reference, ref argument. Eg.: void foo[lifetime lt](int scope(lt)* x){ ...} void foo[lifetime lt](scope(lt) C c){ ... } void foo[lifetime lt](scope(lt) ref int x){ ... } void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ ... } (The last example talks about a slice where the array memory has different lifetimes than the class instances it contains.) - Lifetime intersection: Eg.: scope(lt1&lt2)Tuple!(int*,int*) pair[lifetime lt1,lifetime lt2](int scope(lt1)* p1, int scope(lt1)* p2){ ... } (It can alternatively be done only implicitly at function boundaries.) - Specifying the lifetime of a struct/class upon construction: Eg.: struct S[lifetime lt1,lifetime lt2]{ ... this(int scope(lt1)* x, int scope(lt2)* y)scope(lt1&lt2){ ... } }
...

 For those that want a non-nullable reference type. This should be
 doable
 as a library type.
No.
Rationale?
null
??
My point exactly. http://xkcd.com/641/ Also, there will be the usual problems with subtyping.
Jul 09 2014
next sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
On Thursday, 10 July 2014 at 03:12:24 UTC, Timon Gehr wrote:
 I don't know, but I assume it would have to be competitive with 
 what Rust provides.
I think the Rust team found that implementing a sound borrow-checker was basically impossible without requiring lifetime annotations in some cases. So if D wanted to go down the Rust route, it'd have to be willing to add new syntax for lifetime annotations (although these can apparently be inferred in most cases so aren't often required).
Jul 09 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 05:12:23AM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
 - Lifetime parameters. (it's more future-proof if they are not
 introduced by simple identifiers.)
 
 Eg.: void foo[lifetime lt](int x){ ... }
 
 
 - Attaching a lifetime to a pointer, class reference, ref argument.
 
 Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
      void foo[lifetime lt](scope(lt) C c){ ... }
      void foo[lifetime lt](scope(lt) ref int x){ ... }
      void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ ... }
 
 (The last example talks about a slice where the array memory has
 different lifetimes than the class instances it contains.)
[...] This is starting to look like some parts of my 'scope' proposal in another part of this thread. I'm wondering if it makes sense to simplify lifetimes by tying them to lexical context rather than using explicit annotations? Being able to specify explicit lifetimes seem a bit excessive to me, but perhaps you have a use case in mind that I'm not aware of? T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Jul 09 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2014 07:41 AM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Jul 10, 2014 at 05:12:23AM +0200, Timon Gehr via Digitalmars-d wrote:
 [...]
 - Lifetime parameters. (it's more future-proof if they are not
 introduced by simple identifiers.)

 Eg.: void foo[lifetime lt](int x){ ... }


 - Attaching a lifetime to a pointer, class reference, ref argument.

 Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
       void foo[lifetime lt](scope(lt) C c){ ... }
       void foo[lifetime lt](scope(lt) ref int x){ ... }
       void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ ... }

 (The last example talks about a slice where the array memory has
 different lifetimes than the class instances it contains.)
[...] This is starting to look like some parts of my 'scope' proposal in another part of this thread. I'm wondering if it makes sense to simplify lifetimes
(This is not complicated.)
 by tying them to lexical context
They are.
 rather than using explicit annotations?
Suitable rules can be added to automatically do some sensible thing by default, but I don't think it makes sense to try and guess suitable lifetimes just by staring at a function signature in the general case.
 Being able to
 specify explicit lifetimes seem a bit excessive to me, but perhaps you
 have a use case in mind that I'm not aware of?
...
If lifetimes cannot transcend function invocations, this is a serious limitation, don't you agree? How would you do e.g. an identity function on a borrowed pointer type, to name a simple example?
Jul 09 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 8:12 PM, Timon Gehr wrote:
 3. have a design and a plan that gets there

 There's no law that says D refs must be exactly like Rust borrowed. We
 can come up with a design that works best for D. D != Rust. Do you have
 a design in mind?
 ...
Roughly, but not with 'ref'. It is also an issue of syntax at this point. I think we should get at least the basics fixed there before talking in-depth about semantics. (In any case, I still have one DIP pending in an unacceptable state that I couldn't find the time to write down properly yet.)
 Fundamentally, we need syntax for (examples provided for illustration, those
are
 not proposals):

 - Parametric polymorphism

 Eg.: void foo[A](int x){ ... }
What does that do?
 - Lifetime parameters. (it's more future-proof if they are not introduced by
 simple identifiers.)

 Eg.: void foo[lifetime lt](int x){ ... }
??
 - Attaching a lifetime to a pointer, class reference, ref argument.

 Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
       void foo[lifetime lt](scope(lt) C c){ ... }
       void foo[lifetime lt](scope(lt) ref int x){ ... }
       void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ ... }

 (The last example talks about a slice where the array memory has different
 lifetimes than the class instances it contains.)
This seems awfully complicated.
 - Lifetime intersection:

 Eg.: scope(lt1&lt2)Tuple!(int*,int*) pair[lifetime lt1,lifetime lt2](int
 scope(lt1)* p1, int scope(lt1)* p2){ ... }

 (It can alternatively be done only implicitly at function boundaries.)


 - Specifying the lifetime of a struct/class upon construction:

 Eg.: struct S[lifetime lt1,lifetime lt2]{
           ...
           this(int scope(lt1)* x, int scope(lt2)* y)scope(lt1&lt2){ ... }
       }
Jul 09 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2014 08:59 AM, Walter Bright wrote:
 On 7/9/2014 8:12 PM, Timon Gehr wrote:
 3. have a design and a plan that gets there

 There's no law that says D refs must be exactly like Rust borrowed. We
 can come up with a design that works best for D. D != Rust. Do you have
 a design in mind?
 ...
...
 Fundamentally, we need syntax for (examples provided for illustration,
 those are
 not proposals):

 - Parametric polymorphism

 Eg.: void foo[A](int x){ ... }
What does that do? ...
It's a mechanism for compile-time parameters with homogeneous translation. (It is sufficient if it supports lifetimes at this point, but inout could profit as well.) We get a (potentially) differently typed function 'foo' for every argument `A', but it is the same function at runtime, hence this works for virtual methods and function pointers/delegates.
 - Lifetime parameters. (it's more future-proof if they are not
 introduced by
 simple identifiers.)

 Eg.: void foo[lifetime lt](int x){ ... }
?? ...
This introduces a compile-time parameter that is a lifetime. (It's not a use case, just an example.)
 - Attaching a lifetime to a pointer, class reference, ref argument.

 Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
       void foo[lifetime lt](scope(lt) C c){ ... }
       void foo[lifetime lt](scope(lt) ref int x){ ... }
       void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[]
 a){ ... }

 (The last example talks about a slice where the array memory has
 different
 lifetimes than the class instances it contains.)
This seems awfully complicated. ...
Are you talking about the concept, the examples, or just the last example? What makes it seem complicated?
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 11:53 AM, Timon Gehr wrote:
 Are you talking about the concept, the examples, or just the last example? What
 makes it seem complicated?
I can't imagine users going to the bother of typing all that, let alone what happens when they do it wrong. Most users don't really have a good handle on what the lifetimes of their data are, so how are they going to annotate it correctly?
Jul 10 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I can't imagine users going to the bother of typing all that, 
 let alone what happens when they do it wrong. Most users don't 
 really have a good handle on what the lifetimes of their data 
 are, so how are they going to annotate it correctly?
I suggest you to go in the Rust mailing list and ask this question again. Bye, bearophile
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 1:52 PM, bearophile wrote:
 Walter Bright:

 I can't imagine users going to the bother of typing all that, let alone what
 happens when they do it wrong. Most users don't really have a good handle on
 what the lifetimes of their data are, so how are they going to annotate it
 correctly?
I suggest you to go in the Rust mailing list and ask this question again.
Rust has very little experience in real projects. I know that people see all the hype about Rust and believe it has proved itself, but it hasn't. I've read other papers about annotations in Java and how people just refused to annotate their references.
Jul 10 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 10 July 2014 at 22:50:51 UTC, Walter Bright wrote:
 On 7/10/2014 1:52 PM, bearophile wrote:
 Walter Bright:

 I can't imagine users going to the bother of typing all that, 
 let alone what
 happens when they do it wrong. Most users don't really have a 
 good handle on
 what the lifetimes of their data are, so how are they going 
 to annotate it
 correctly?
I suggest you to go in the Rust mailing list and ask this question again.
Rust has very little experience in real projects. I know that people see all the hype about Rust and believe it has proved itself, but it hasn't. I've read other papers about annotations in Java and how people just refused to annotate their references.
This might have something to do with both the mindset of Java ("isn't the runtime supposed to take care of this sort of thing?") and the fact that Java is already monstrously verbose.
Jul 11 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 10 July 2014 at 20:41:55 UTC, Walter Bright wrote:
 On 7/10/2014 11:53 AM, Timon Gehr wrote:
 Are you talking about the concept, the examples, or just the 
 last example? What
 makes it seem complicated?
I can't imagine users going to the bother of typing all that, let alone what happens when they do it wrong. Most users don't really have a good handle on what the lifetimes of their data are, so how are they going to annotate it correctly?
It doesn't need to be specified manually everywhere: * For templates, it can be inferred. * Local variables are either the objects _to which_ references are borrowed, in which case no annotation is necessary, or the contain returned values from functions, in which case `auto` can be used. * Even most methods and library functions can just mark their parameters as `scope` (or whatever the syntax will be), without any mentioning of a lifetime or owner. That leaves relatively few cases where either a reference to a passed-in parameter is returned (e.g. typical haystack-needle operations), or (more unusual), a passed in value is being kept around temporarily, e.g. as a member of a struct. This could be reduced even more for pure functions, where the compiler can automatically allow borrowing if it's clear from the parameter and return types that no reference to the argument can be escaped.
Jul 10 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 10 July 2014 at 20:57:09 UTC, Marc Schütz wrote:
 * Even most methods and library functions can just mark their 
 parameters as `scope` (or whatever the syntax will be), without 
 any mentioning of a lifetime or owner.
And the fact that `in` is defined as `const scope` fits nicely here.
Jul 10 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 1:57 PM, "Marc Schütz" <schuetzm gmx.net>" wrote:
 That leaves relatively few cases
Right, and do those cases actually matter? I'm a big believe in attribute inference, because explicit attributes are generally a failure with users.
Jul 10 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 10 July 2014 at 22:53:18 UTC, Walter Bright wrote:
 On 7/10/2014 1:57 PM, "Marc Schütz" <schuetzm gmx.net>" wrote:
 That leaves relatively few cases
Right, and do those cases actually matter?
Besides what I mentioned there is also slicing and ranges (not only of arrays). These are more likely to be implemented as templates, though.
 I'm a big believe in attribute inference, because explicit 
 attributes are generally a failure with users.
The average end user probably doesn't need to use explicit annotations a lot, but they need to be there for library authors. I don't think it's possible to avoid annotations completely but still get the same functionality just by inferring them internally, if that is what you're aiming at...
Jul 11 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/10/2014 10:41 PM, Walter Bright wrote:
 On 7/10/2014 11:53 AM, Timon Gehr wrote:
 Are you talking about the concept, the examples, or just the last
 example? What
 makes it seem complicated?
I can't imagine users going to the bother of typing all that,
As explicitly stated this was just for demonstration. Feel free to propose concise syntax.
 let alone
 what happens when they do it wrong. Most users don't really have a good
 handle on what the lifetimes of their data are, so how are they going to
 annotate it correctly?
If they do it wrong it is not going to compile.
Jul 10 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This 
 should be doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Jul 09 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2014 11:59 PM, deadalnix wrote:
 On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Please point me to where it was.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 12:23 AM, Walter Bright wrote:
 On 7/9/2014 11:59 PM, deadalnix wrote:
 On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Please point me to where it was.
Or better yet, what is your proposal?
Jul 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/10/14, 12:54 AM, Walter Bright wrote:
 On 7/10/2014 12:23 AM, Walter Bright wrote:
 On 7/9/2014 11:59 PM, deadalnix wrote:
 On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be
 doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Please point me to where it was.
Or better yet, what is your proposal?
DIP please. -- Andrei
Jul 10 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/9/14, 11:59 PM, deadalnix wrote:
 On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be
 doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Yes, the arguments come and go by in forum discussions. To avoid this we need a well-written DIP that has a section illustrating the insufficiencies of library solutions, and then proposes the few needed additions to the language that make the thing work properly. Other language communities have done this with good results. Andrei
Jul 10 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 6:51 AM, Andrei Alexandrescu wrote:
 On 7/9/14, 11:59 PM, deadalnix wrote:
 On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be
 doable
 as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and again.
Yes, the arguments come and go by in forum discussions. To avoid this we need a well-written DIP that has a section illustrating the insufficiencies of library solutions, and then proposes the few needed additions to the language that make the thing work properly. Other language communities have done this with good results.
Yup. Otherwise this will come up again and again and again and again. :-)
Jul 10 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 10 July 2014 at 13:51:42 UTC, Andrei Alexandrescu 
wrote:
 Yes, the arguments come and go by in forum discussions. To 
 avoid this we need a well-written DIP that has a section 
 illustrating the insufficiencies of library solutions, and then 
 proposes the few needed additions to the language that make the 
 thing work properly. Other language communities have done this 
 with good results.

 Andrei
I've made several DIPs. Some of them solving existing problems being discussed right now (what happen with delegates when you have this + context for instance, is solved). Most of them never gathered any attention. I'm willing to write this one as well, but my time isn't infinite, and ultimately, every time I do something like this, it is time I don't spend on SDC. Considering the attention these get, I simply cannot put this in high position in my priority queue.
Jul 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2014 10:53 PM, deadalnix wrote:
 Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and push it. "Build it and they will come" is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is. The DIPs were for things that looked obscure and were technically complex, a surefire recipe for a collective yawn even though I knew they were crucial (inferring uniqueness). If you're looking for lots of comments, start a nice bikeshedding thread about whitespace conventions :-)
Jul 12 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 12 Jul 2014 13:27:26 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 7/10/2014 10:53 PM, deadalnix wrote:
 Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and push it. "Build it and they will come" is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is. The DIPs were for things that looked obscure and were technically complex, a surefire recipe for a collective yawn even though I knew they were crucial (inferring uniqueness). If you're looking for lots of comments, start a nice bikeshedding thread about whitespace conventions :-)
But you've got some nice bonus: If somebody doesn't like your pull request you can just merge it anyway. But if you veto something the only one who can probably merge anyway is Andrei.
Jul 12 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/12/14, 1:38 PM, Johannes Pfau wrote:
 But you've got some nice bonus:
 If somebody doesn't like your pull request you can just merge it anyway.
That hasn't happened in a really long time, and last time it did is before we had due process in place.
 But if you veto something the only one who can probably merge anyway is
 Andrei.
Such situations are best resolved by building consensus and a shared vision. Andrei
Jul 12 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/12/2014 1:38 PM, Johannes Pfau wrote:
 But you've got some nice bonus:
 If somebody doesn't like your pull request you can just merge it anyway.
I'd only do that in an emergency. I'll also just pull the ones for D1.
 But if you veto something the only one who can probably merge anyway is
 Andrei.
Andrei and I don't always agree, but we've not gone around overriding each other.
Jul 12 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/12/14, 1:27 PM, Walter Bright wrote:
 On 7/10/2014 10:53 PM, deadalnix wrote:
 Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and push it. "Build it and they will come" is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is.
Indeed that's how it is. It's also a quality issue - we can reasonably assume that a perfect slam-dunk DIP would be easily recognized; many of the current DIPs (including mine) need work and dedication, which is more difficult to find. Andrei
Jul 12 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Jul-2014 01:22, Walter Bright пишет:
 Distilling the discussions about D that are elsewhere than this forum,
 some consistent themes emerge which we need to address to broaden the
 appeal of D. All of them require some organization and focussed effort
 to complete.

 There's been enough jawboning about them. I figure all of them can be
 smartly blown to smithereens if we just line up 3 or 4 cannons on each.
...
 8. NotNull!T type

 For those that want a non-nullable reference type. This should be doable
 as a library type.
Not digging into the whole thread. 9. Extensible I/O package to replace our monolitic std.stdio sitting awkwardly on top of C's legacy. That would imply integrating it with sockets/pipes and filters/codecs (compression, transcoding and the like) as well. I was looking of into it with Steven, but currently have little spare time (and it seems he does too). I'd gladly guide a capable recruit to join the effort in proper rank. -- Dmitry Olshansky
Jul 10 2014
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 10 July 2014 at 21:29:30 UTC, Dmitry Olshansky wrote:
 Not digging into the whole thread.

 9. Extensible I/O package to replace our monolitic std.stdio 
 sitting awkwardly on top of C's legacy. That would imply 
 integrating it with sockets/pipes and filters/codecs 
 (compression, transcoding and the like) as well.

 I was looking of into it with Steven, but currently have little 
 spare time (and it seems he does too). I'd gladly guide a 
 capable recruit to join the effort in proper rank.
A short write up of where Steven left off on his work would probably help kickstart this. I remember you had some great ideas for handling buffering but it changed a few times during that thread and I don't remember what the final idea was.
Jul 11 2014
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
I think Walter is exactly right with the first 7 points he is 
listing in his starting post of this thread. Nullable types are 
nice, but don't get too much distracted by them. The first 7 
points are far more important. Go takes absolutely no effort to 
get rid of nil and they are very successful in despite of this 
nil thing.

IMHO goroutines and channels is really the key. D might be a 
better C++. But languages need a use case to make people change. 
I don't see why D can't do for cloud computing and concurrent 
server-side software what Go is doing. Go's GC is also not that 
advanced, but it is precise so 24/7 is not a problem. Making the 
D GC precise is more important than making it faster.

Actually, you get the strange situation now that to make D a 
language for the cloud a quick approach would be to make 
everything GC and let people have pointers as well as in Go. Of 
course, no good approach for the long run prospects of D. But let 
all memory management be handled by the GC should remain easy in 
D. Otherwise, D will be for the systems people only as with Rust.

Much of the froth about Go is dismissed by serious developers, 
but they nailed the goroutine thing. It's Go's killer feature.
I think so, too. Along with channels and channel selects to coordinate all those goroutines and exchange data between them. Without them goroutines would be pointless except for doing things in parallel. I'm not sure you can do selects in the library with little lock contention, but I'm not an expert on this.
Think of it from the perspective of attracting Erlang 
programmers, or Java/Scala programmers who use Akka.
Not wanting to be rude, but you don't stand a chance with that. Java has Hadoop, MongoDB, Hazelcast, Akka, Scala, Cassandra and MUCH more. No way you can beat all that. Hordes of average Java developers that will be against you, because they know Java and nothing else and don't want to loose their status. But Go also does not have these things. It's success is huge, though, and it seems mostly to be attributed to goroutines and channels. This made Go the "language for the cloud" (at least other people say so), which is what there is a need for now. Other than that Go is drop dead simple. You can start coding now and start your cloud software start-up now. There is nothing complicated you need to learn. D cannot compete with that (thank goodness it is also no minimalistic language like Go).
Akka similarly uses its own lightweight threads, not heavyweight 
JVM threads.
Akka uses some approach like Apple's Grand Central Dispatch. As I understand it so does vibe.d (using libevent). A small number of threads is serving queues to which tasks are added. This works fine as long as those tasks are short runners. You can have 50.000 long runners in Go. As long as they aren't all active the system is well responsive. You can't have 50.000 long-runners in Akka, because they would block all kernel threads that serve the task queues. The 50.000 and first long running task will have to wait a long time till it will be served. This is why they have special worker threads in Vert.x for Java: threads that are reserved for long-runners (and you can't have many of them).
Aug 10 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-08-10 at 09:27 +0000, Bienlein via Digitalmars-d wrote:
[=E2=80=A6]
 IMHO goroutines and channels is really the key. D might be a=20
 better C++. But languages need a use case to make people change.=20
=46rom a marketing perspective, Go introduced goroutines (which is an implementation of a minor variant of CSP more or less), Rust introduces lots of things about memory management, references, etc. C and C++ have none of these. What does D bring to the field that is new today so that it can be used as a marketing tool? [=E2=80=A6]
 But Go also does not have these things. It's success is huge,=20
 though, and it seems mostly to be attributed to goroutines and=20
 channels. This made Go the "language for the cloud" (at least=20
 other people say so), which is what there is a need for now.=20
 Other than that Go is drop dead simple. You can start coding now=20
 and start your cloud software start-up now. There is nothing=20
 complicated you need to learn. D cannot compete with that (thank=20
 goodness it is also no minimalistic language like Go).
The core point about Go is goroutines: it means you don't have to do all this event loop programming and continuations stuff =C3=A0 la Node, Vert.x, Vibe.d, you can use processes and channels and the scheduling is handled at the OS level. No more shared memory stuff. OK so all this event loop, asyncio stuff is hip and cool, but as soon as you have to do something that is not zero time wrt event arrival, it all gets messy and complicated. (Over simplification, but true especially in GUI programming.) Go is otherwise a trimmed down C and so trivial (which turns out to be a good thing) but it also has types, instances and extension methods which are new and shiny and cool (even though they are not new nor shiny). These new things capture hearts and minds and create new active communities. It is true that Go is a "walled garden" approach to software, the whole package and executable management system is introvert and excludes. But it creates a space in which people can work without distraction.=20 Dub has the potential to do for D what Go's package system and import from DVCS repositories has done, and that is great. But it is no longer new. D is just a "me too" language in that respect.
Akka similarly uses its own lightweight threads, not heavyweight=20
JVM threads.
=20 Akka uses some approach like Apple's Grand Central Dispatch. As I=20 understand it so does vibe.d (using libevent). A small number of=20 threads is serving queues to which tasks are added. This works=20 fine as long as those tasks are short runners. You can have=20 50.000 long runners in Go. As long as they aren't all active the=20 system is well responsive. You can't have 50.000 long-runners in=20 Akka, because they would block all kernel threads that serve the=20 task queues. The 50.000 and first long running task will have to=20 wait a long time till it will be served. This is why they have=20 special worker threads in Vert.x for Java: threads that are=20 reserved for long-runners (and you can't have many of them).
And Erlang. And GPars. And std.parallelism. It is the obviously sensible approach to management of multiple activities. D brings nothing new on this front. What no native code language (other than C++ in Anthony Williams' Just::Thread Pro in vestigial form) has is dataflow. This is going to be big in JVM-land fairly soon (wel actually it already is but no-one is talking about it much because of commercial vested interests) So if D got CSP, it would be me too but useful. If D got dataflow it would be "D the first language to support dataflow in native code systems". Now that could sell. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Aug 10 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 10 August 2014 at 10:00:45 UTC, Russel Winder via 
Digitalmars-d wrote:
 So if D got CSP, it would be me too but useful. If D got 
 dataflow it
 would be "D the first language to support dataflow in native 
 code
 systems". Now that could sell.
Yes, that would be cool, but what do you mean specifically with "dataflow"? Apparently it is used to describe everything from tuple spaces to DSP engines. I think dataflow in combination with transactional memory (Haswell and newer CPUs) could be a killer feature. (I agree that CSP would be too much me too unless you build everything around it.)
Aug 11 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-08-11 at 11:02 +0000, via Digitalmars-d wrote:
[=E2=80=A6]
 Yes, that would be cool, but what do you mean specifically with=20
 "dataflow"? Apparently it is used to describe everything from=20
 tuple spaces to DSP engines.
I guess it is true that tuple spaces can be dataflow systems, as indeed can Excel. DSP engines are almost all dataflow exactly because signal processing is a dataflow problem. For me, software dataflow architecture is processes with input channels and output channels where the each process only computes on the receipt of data ready on some a combination of its inputs. I guess my exemplar framework is GPars dataflow http://www.gpars.org/1.0.0/guide/guide/dataflow.html
 I think dataflow in combination with transactional memory=20
 (Haswell and newer CPUs) could be a killer feature.
V=C3=A1clav Pech, myself and others been discussing the role of STM but haven't really come to a conclusion. STM is definitely a great tool for virtual machine, framework and library developers, but it is not certain is is a useful general applications tool.
 (I agree that CSP would be too much me too unless you build=20
 everything around it.)
I disagree. Actors, dataflow and CSP are all different. Although each can be constructed from one of the others, true, but it leads to inefficiencies. It turns out to be better to implement all three separately based on a lower-level set of primitives. Technically a CSP implementation has proof obligations to be able to claim to be CSP. As far as I am aware the only proven implementations are current JCSP and C++CSP2. D has the tools needed as shown by std.parallelism. If it could get actors, CSP and dataflow then it would have something new to tell the world about to be able to compete in the marketing stakes with Go and Rust. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Aug 11 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 11 August 2014 at 15:13:43 UTC, Russel Winder via 
Digitalmars-d wrote:
 For me, software dataflow architecture is processes with input 
 channels
 and output channels where the each process only computes on the 
 receipt
 of data ready on some a combination of its inputs.
Yes, but to get efficiency you need to make sure to take advantage of cache coherency…
 I think dataflow in combination with transactional memory 
 (Haswell and newer CPUs) could be a killer feature.
Václav Pech, myself and others been discussing the role of STM but haven't really come to a conclusion. STM is definitely a great tool for virtual machine, framework and library developers, but it is not certain is is a useful general applications tool.
Really? I would think that putting TM to good use would be difficult without knowing the access patterns, so it would be more useful for engine and application developers…? You essentially want to take advantage of a low probability of accessing the same cache-lines within a transaction, otherwise it will revert to slow locking. So you need to minimize the probability of concurrent access.
 (I agree that CSP would be too much me too unless you build 
 everything around it.)
I disagree. Actors, dataflow and CSP are all different. Although each can be constructed from one of the others, true, but it leads to inefficiencies. It turns out to be better to implement all three separately based on a lower-level set of primitives.
I am thinking more of the eco-system. If you try to support too many paradigms you end up with many small islands which makes building applications more challenging and source code more difficult to read. I think dataflow would be possible to work into the range-based paradigm that D libraries seems to follow. C++ is good example of the high eco system costs of trying to support everything, but very little out of the box. You basically have to select one primary framework and then try to shoehorn other reusable components into that framework by ugly layers of glue…
Aug 11 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 11 August 2014 at 15:42:17 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 11 August 2014 at 15:13:43 UTC, Russel Winder via ...

 C++ is good example of the high eco system costs of trying to 
 support everything, but very little out of the box. You 
 basically have to select one primary framework and then try to 
 shoehorn other reusable components into that framework by ugly 
 layers of glue…
So is the cost of trying not to have an healthy set of libraries as part of the standard like the other programming languages. Thanks to the C tradition that the language library is the OS. Thankfully, the standard is now catching up and will eventually cover a good set of use cases in the standard library. However, there is code legacy code out there that doesn't know anything about ANSI standard revisions. -- Paulo
Aug 15 2014
parent "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 15 August 2014 at 12:49:37 UTC, Paulo Pinto wrote:
 So is the cost of trying not to have an healthy set of 
 libraries as part of the standard like the other programming 
 languages. Thanks to the C tradition that the language library 
 is the OS.

 Thankfully, the standard is now catching up and will eventually 
 cover a good set of use cases in the standard library.
I think the importance of standard libraries are overrated beyond core building blocks for real system programming. You usually want to use the ADTs of the environment to avoid format conversions or fast domain specific solutions for performance. If you want FFT you need to look for the best hardware library you can find, no language library willl be good enough. Same with unwrapping of complex numbers to magnitude/phase, decimation and a lot of other standard routines. Libraries with no domain in mind tend to suck. So performant frameworks tend to roll their own. I think phobos is aiming too wide, it would be better to focus on quality and performance for the core stuff based on real use and benchmarking. A benchmarking suite seems to be missing? A good clean stable language and compiler is sufficient. A library with core building blocks that can be composed is a nice extra. Phobos should be more focused. Too much added and you end up with underperformant solutions, unmaintained code, untested buggy code, or weird interfaces, e.g. lowerBound() that returns the inverse of what the name indicates, walkLength() that does not take a visitor object etc. Providing good solid interconnects / abstractions are more important than functionality and solutions for growing the eco system. In python the key interconnect feature is having solid language level support for lists/dicts. C++ tried iterators, but it is tedious to define your own and tend to be underperformant, so frameworks might not want to use them. D is trying ranges... But without benchmarks... Who knows how it fares in comparison to a performance oriented algorithm?
Aug 20 2014
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.08.2014 13:02, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":
 I think dataflow in combination with transactional memory (Haswell and
 newer CPUs) could be a killer feature.
FYI: Intel TSX is not a thing anymore, it turned out to be buggy and is disabled by a microcode update now: http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus Seems like even the upcoming Haswell-EP Xeons will have it disabled. Cheers, Daniel
Aug 15 2014