October 02, 2014
On Thursday, 2 October 2014 at 11:41:14 UTC, Jacob Carlborg wrote:
> I haven't really thought how it could be implemented but I was hoping that the caller could magically decide the allocation strategy instead of the callee. It looks like Rust is doing something like that but I haven't looked at it in detail.

I haven't looked at Rust in detail, but doesn't the Rust compiler take full control over memory management? I think that is a good idea, but it is at odds with D's general direction.

October 02, 2014
On Thursday, 2 October 2014 at 13:29:58 UTC, Ola Fosheim Grøstad
wrote:
> On Thursday, 2 October 2014 at 11:41:14 UTC, Jacob Carlborg wrote:
>> I haven't really thought how it could be implemented but I was hoping that the caller could magically decide the allocation strategy instead of the callee. It looks like Rust is doing something like that but I haven't looked at it in detail.
>
> I haven't looked at Rust in detail, but doesn't the Rust compiler take full control over memory management? I think that is a good idea, but it is at odds with D's general direction.

Rust makes use of the type system and the borrow checker to
validate how the pointers are being used.

The usual errors when dealing with pointers are compile time
errors in Rust.

--
Paulo
October 02, 2014
On Thursday, 2 October 2014 at 18:52:18 UTC, Paulo Pinto wrote:
> Rust makes use of the type system and the borrow checker to
> validate how the pointers are being used.
>
> The usual errors when dealing with pointers are compile time
> errors in Rust.

They constrain usage so that you cannot share mutable objects. It is described in reasonable high level here:

http://doc.rust-lang.org/0.11.0/rust.html#memory-and-concurrency-models

But is sketchy on implementation details, semantic restrictions that follows and consequences when interacting with foreign code etc.
October 02, 2014
On Thursday, 2 October 2014 at 19:45:17 UTC, Ola Fosheim Grøstad wrote:
> But is sketchy on implementation details, semantic restrictions that follows and consequences when interacting with foreign code etc.

Some Rust details. «sendable» means that a reference can be transferred to another thread (or task/fiber/whatever).

From http://doc.rust-lang.org/std/gc/ :

«The Gc type provides shared ownership of an immutable value. Destruction is not deterministic, and will occur some time between every Gc handle being gone and the end of the task. The garbage collector is task-local so Gc<T> is not sendable.»

From http://doc.rust-lang.org/std/rc/index.html :

«The Rc type provides shared ownership of an immutable value. Destruction is deterministic, and will occur as soon as the last owner is gone. It is marked as non-sendable because it avoids the overhead of atomic reference counting.

The downgrade method can be used to create a non-owning Weak pointer to the box. A Weak pointer can be upgraded to an Rc pointer, but will return None if the value has already been freed.»

So… they don't really solve the issues a @nogc version of D should be able to deal with beyond having built-in unique_ptr style semantics?

Or?
October 02, 2014
On Thursday, 2 October 2014 at 20:10:42 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 2 October 2014 at 19:45:17 UTC, Ola Fosheim Grøstad wrote:
>> But is sketchy on implementation details, semantic restrictions that follows and consequences when interacting with foreign code etc.
>
> Some Rust details. «sendable» means that a reference can be transferred to another thread (or task/fiber/whatever).
>
> From http://doc.rust-lang.org/std/gc/ :
>
> «The Gc type provides shared ownership of an immutable value. Destruction is not deterministic, and will occur some time between every Gc handle being gone and the end of the task. The garbage collector is task-local so Gc<T> is not sendable.»
>
> From http://doc.rust-lang.org/std/rc/index.html :
>
> «The Rc type provides shared ownership of an immutable value. Destruction is deterministic, and will occur as soon as the last owner is gone. It is marked as non-sendable because it avoids the overhead of atomic reference counting.
>
> The downgrade method can be used to create a non-owning Weak pointer to the box. A Weak pointer can be upgraded to an Rc pointer, but will return None if the value has already been freed.»
>
> So… they don't really solve the issues a @nogc version of D should be able to deal with beyond having built-in unique_ptr style semantics?
>
> Or?

The Gc type is gone as of this week.

https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-09-30.md
October 02, 2014
On Thursday, 2 October 2014 at 20:42:16 UTC, Paulo Pinto wrote:
> The Gc type is gone as of this week.
>
> https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-09-30.md

Thanks, apparently they do it because they want to make a proper tracing gc available later:

https://github.com/pnkfelix/rfcs/blob/fsk-remove-refcounting-gc-of-t/active/0000-remove-refcounting-gc-of-t.md
October 03, 2014
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
> Back when I've first introduced RCString I hinted that we have a larger
> strategy in mind. Here it is.

[snip]

I think it would be well worth it to actually do a bit of research.
Before we get into the fry and spill blood (or LOCs) everywhere.

Can we:

1. Present a list of allocating functions.

2. What they (currently) allocate: string, T[], V[K] or something else.

3. See what alternatives they have (that do not allocate if any).

4. Plot course for these that do not have. (Just listing how function signature would change is good enough).

Thanks!

P.S. If there are no takers I'd get do myself it in a week or so.

-- 
Dmitry Olshansky
October 03, 2014
On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
> 29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>> Back when I've first introduced RCString I hinted that we have a larger
>> strategy in mind. Here it is.
>
> [snip]
>
> I think it would be well worth it to actually do a bit of research.
> Before we get into the fry and spill blood (or LOCs) everywhere.
>
> Can we:
>
> 1. Present a list of allocating functions.

Awesome. I just started http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage and I encourage us all to add to it (sorted by module and then by artifact name).

> 2. What they (currently) allocate: string, T[], V[K] or something else.

Mention that in the "Possible Fix(es)" column.

> 3. See what alternatives they have (that do not allocate if any).

Yah.

> 4. Plot course for these that do not have. (Just listing how function
> signature would change is good enough).

Yah.

> Thanks!
>
> P.S. If there are no takers I'd get do myself it in a week or so.

Let's all get this rolling!


Andrei

October 03, 2014
03-Oct-2014 23:50, Andrei Alexandrescu пишет:
> On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
>> 29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>>> Back when I've first introduced RCString I hinted that we have a larger
>>> strategy in mind. Here it is.
>>
>> [snip]
>>
>> I think it would be well worth it to actually do a bit of research.
>> Before we get into the fry and spill blood (or LOCs) everywhere.
>>
>> Can we:
>>
>> 1. Present a list of allocating functions.
>
> Awesome. I just started
> http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage and I
> encourage us all to add to it (sorted by module and then by artifact name).

Glad you liked it.

Being in favor of automation as a start I just toggled -vgc flag in Win64 makefile and built phobos. Raw data (CSV) is here:

https://gist.github.com/anonymous/763adcd62ab60a66e9d8

Time to mine it...

-- 
Dmitry Olshansky
October 03, 2014
On 10/3/14, 1:18 PM, Dmitry Olshansky wrote:
> 03-Oct-2014 23:50, Andrei Alexandrescu пишет:
>> On 10/3/14, 11:27 AM, Dmitry Olshansky wrote:
>>> 29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>>>> Back when I've first introduced RCString I hinted that we have a larger
>>>> strategy in mind. Here it is.
>>>
>>> [snip]
>>>
>>> I think it would be well worth it to actually do a bit of research.
>>> Before we get into the fry and spill blood (or LOCs) everywhere.
>>>
>>> Can we:
>>>
>>> 1. Present a list of allocating functions.
>>
>> Awesome. I just started
>> http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage and I
>> encourage us all to add to it (sorted by module and then by artifact
>> name).
>
> Glad you liked it.
>
> Being in favor of automation as a start I just toggled -vgc flag in
> Win64 makefile and built phobos. Raw data (CSV) is here:
>
> https://gist.github.com/anonymous/763adcd62ab60a66e9d8
>
> Time to mine it...

D script that generates wikitable from that -> awesomeness. -- Andrei