On Tuesday, 23 September 2014 at 16:18:33 UTC, Andrei Alexandrescu wrote:
> The offer was in the context of a feature that was being rejected. -- Andrei

Walter *has* said before that he's uncomfortable with tools that directly modify source code, which is understandable. A good suggestion was to not directly modify the source, but produce a patch file that can be used by any merge tool (and maybe an option to directly modify a file if someone really wants to).

On 9/23/14, 11:08 AM, Meta wrote:
> On Tuesday, 23 September 2014 at 16:18:33 UTC, Andrei Alexandrescu wrote:
>> The offer was in the context of a feature that was being rejected. --
>> Andrei
>
> Walter *has* said before that he's uncomfortable with tools that
> directly modify source code, which is understandable. A good suggestion
> was to not directly modify the source, but produce a patch file that can
> be used by any merge tool (and maybe an option to directly modify a file
> if someone really wants to).

I've been at a conference where Pike spoke about gofix. He convinced me it's a very valuable tool. -- Andrei

On Tue, 23 Sep 2014 18:08:45 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Walter *has* said before that he's uncomfortable with tools that directly modify source code, which is understandable.
i can't understand this, though. any big project using SCM nowdays, and it's easy to create branch and work on it. and even 'hello, world' projects can use modern DVCS with two or three commands. there is nothing wrong with source code modifications, and patches can be made later, by something like 'git diff'.

the only poor fellas are those who forced to use svn by "company standards". ah, ignore 'em, they don't mind having some more pain (that's why they still using svn, aren't they?).

On Tuesday, 23 September 2014 at 18:08:46 UTC, Meta wrote:
> On Tuesday, 23 September 2014 at 16:18:33 UTC, Andrei Alexandrescu wrote:
>> The offer was in the context of a feature that was being rejected. -- Andrei
>
> Walter *has* said before that he's uncomfortable with tools that directly modify source code, which is understandable. A good suggestion was to not directly modify the source, but produce a patch file that can be used by any merge tool (and maybe an option to directly modify a file if someone really wants to).

We are in 2014, and we have good source control. That will be fine.

23-Sep-2014 19:13, Andrei Alexandrescu пишет:
> On 9/23/14, 12:17 AM, Dmitry Olshansky wrote:
>> In my imagination it would be along the lines of
>> @ARC
>> struct MyCountedStuff{ void opInc(); void opDec(); }
>
> So that would be a pointer type or a value type? Is there copy on write
> somewhere? -- Andrei

It would be an intrusively counted type with pointer somewhere in the body. To put it simply MyCountedStuff is a kind of smart pointer.

-- 
Dmitry Olshansky

23-Sep-2014 16:17, Manu via Digitalmars-d пишет:
> On 23 September 2014 17:17, Dmitry Olshansky via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> 23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
>>>
>>> On 23 September 2014 16:19, deadalnix via Digitalmars-d
>>> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>>
>>>      On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
>>>      Digitalmars-d wrote:
>>>
>>>          I still think most of those users would accept RC instead of GC.
>>>          Why not
>>>          support RC in the language, and make all of this library noise
>>>          redundant?
>>>          Library RC can't really optimise well, RC requires language
>>>          support to
>>>          elide ref fiddling.
>>>
>>>
>>>      I think a library solution + intrinsic for increment/decrement (so
>>>      they can be better optimized) would be the best option.
>>>
>>>
>>> Right, that's pretty much how I imagined it too. Like ranges, where
>>> foreach makes implicit calls to contractual methods, there would also be
>>> a contract for refcounted objects, and the compiler will emit implicit
>>> calls to inc/dec if they exist?
>>
>>
>> In my imagination it would be along the lines of
>> @ARC
>> struct MyCountedStuff{ void opInc(); void opDec(); }
>
> Problem with this is you can't make a refcounted int[] without
> mangling the type,

Is that a problem at all? Why should int[] some how become ref-counted. I constantly at loss with strange edge requirements in your questions. Why "mangling" a type is bad?

>and you also can't allocate a ref counted 3rd-party
> type.

Ref-Counted!T or make a wrapper that does call some 3-rd party opInc/opDec.
>
>>> Then we can preserve the type of things, rather than obscuring them in
>>> layers of wrapper templates...
>>
>>
>> This would be intrusive ref-counting which may be more efficient.
>
> Perhaps I'm not clear what you mean by intrusive/non-intrusive?
>

Embed the count vs add a count along the user type.
A use case is for intrusive is to stuff a ref-count into the padding of some struct. A non-intrusive is shared_ptr<T> of C++.


-- 
Dmitry Olshansky

On Monday, 22 September 2014 at 23:09:28 UTC, Andrei Alexandrescu wrote:
> On 9/22/14, 12:18 PM, "Nordlöw" wrote:
>> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
>>> http://dpaste.dzfl.pl/817283c163f5
>>
>> You implementation seems to hold water at least in my tests and save
>> memory at
>>
>> https://github.com/nordlow/justd/blob/master/conceptnet5.d
>
> Awesome, thanks for doing this. How did you measure and what results did you get? -- Andrei

I just checked that I didn't get any segfaults :)

Memory usage in my conceptnet5.d graph (around 1.2GB) didn't differ noticeable when using RCString compared to string in a network that allocates around 10 million RCStrings as keys in a hash-table. Average RCString length is about 14. Is that surprising?

I didn't test speed.

I've found a potential bug in msgpack-d that when fixed enables packing of RCString. See:

https://github.com/msgpack/msgpack-d/issues/43

On 9/24/14, 3:31 AM, Dmitry Olshansky wrote:
> 23-Sep-2014 19:13, Andrei Alexandrescu пишет:
>> On 9/23/14, 12:17 AM, Dmitry Olshansky wrote:
>>> In my imagination it would be along the lines of
>>> @ARC
>>> struct MyCountedStuff{ void opInc(); void opDec(); }
>>
>> So that would be a pointer type or a value type? Is there copy on write
>> somewhere? -- Andrei
>
> It would be an intrusively counted type with pointer somewhere in the
> body. To put it simply MyCountedStuff is a kind of smart pointer.

Then that would be confusing seeing as structs are value types. What you're saying is that a struct with opInc() and opDec() has pointer semantics whereas one with not has value semantics. That design isn't going to fly.

For classes such a design makes sense as long as the class is no longer convertible to Object. That's what I'm proposing for RCObject (and Throwable that would inherit it).


Andrei

On 9/24/14, 4:29 AM, "Nordlöw" wrote:
> On Monday, 22 September 2014 at 23:09:28 UTC, Andrei Alexandrescu wrote:
>> On 9/22/14, 12:18 PM, "Nordlöw" wrote:
>>> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
>>>> http://dpaste.dzfl.pl/817283c163f5
>>>
>>> You implementation seems to hold water at least in my tests and save
>>> memory at
>>>
>>> https://github.com/nordlow/justd/blob/master/conceptnet5.d
>>
>> Awesome, thanks for doing this. How did you measure and what results
>> did you get? -- Andrei
>
> I just checked that I didn't get any segfaults :)
>
> Memory usage in my conceptnet5.d graph (around 1.2GB) didn't differ
> noticeable when using RCString compared to string in a network that
> allocates around 10 million RCStrings as keys in a hash-table. Average
> RCString length is about 14. Is that surprising?

Sounds about reasonable.

> I didn't test speed.

Thanks for this work! -- Andrei

On Wednesday, 24 September 2014 at 14:58:34 UTC, Andrei Alexandrescu wrote:
>> I didn't test speed.

So the pro must be (de)allocation speed then, I suppose?