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