On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
> On Wed, Feb 11, 2015 at 03:20:57AM +0000, weaselcat via Digitalmars-d wrote:
> [...]
>> I was just using RefCounted!T as one example of a major headache I've
>> had with D.
> [...]
>
> Jakob Ovrum has just submitted a PR to make (the current version of)
> RefCounted reject interfaces, since currently it doesn't do that
> correctly (it refcounts the reference to the interface rather than the
> target object).
>
> Given this is the current situation, it would appear to me to make
> RefCounted work with class objects, "all" we have to do would be to
> specialize RefCounted for classes, use malloc to allocate the necessary
> space (plus the refcount, of course), and emplace() the class object
> onto that space. Right?
>
> Of course, given that it has been ... oh, months? years? since
> RefCounted issues have been addressed, I'm probably just kidding myself
> that there are no major monkey wrenches in the works that would make the
> above simplistic solution not work. And I'm not sure I really want to
> know... Not until I have an actual use case for RefCounted in my own
> code, anyway, since otherwise I wouldn't have any confidence that I was

Biggest problem with RefCounted is that it is a struct. Thus it is inherently incompatible with polymorphic world. It is impossible to do reference counted exceptions without language changes (Andrei had proposal about it but it seems to have stalled). It may be possible but not obvious how to do referenced counted interfaces (that point to reference counted classes). It is unclear how one would write in an idiomatic manner a function that accepts object instance without caring if it is GC or ref-counted one (without resorting to templates).

On Wednesday, 11 February 2015 at 08:21:27 UTC, ketmar wrote:
> On Wed, 11 Feb 2015 03:20:57 +0000, weaselcat wrote:
>
>> I'm sure I'll get a response from ketmar( ;-) )
> for your pleasure, sir!
>
> believe me or not, but i almost fully share your opinion. i'm not using
> classes (well, almost), and when i have to, GC is working ok for me. but
> i can see a need in deterministic resource management and classes
> simultaneously. ;-) one of my hobbies is remaking ancient videogames
> (don't ask; i never finished one ;-), so i can understand a desire to
> aviod D GC.

I see it as quite a shame that people repeatedly say they actively avoid using classes in D in favor of structs where possible, until forced to use classes.

On 2/10/15 7:20 PM, weaselcat wrote:
[snip]
> I hope this was the sort of reply you were looking for, Andrei.

Yes, that's good stuff. Thanks! -- Andrei

On 2/11/15 5:48 AM, Dicebot wrote:
> There seems to be a weird miscommunication here. I have asked your
> opinion about this specific proposal - does it seem useful to you, would
> you be willing to endorse it as official starting point for D
> development etc.

Problem is I don't know. That's why I submitted that task https://issues.dlang.org/show_bug.cgi?id=11792 "Investigate...". I'm not a git expert so I don't have answers to a bunch of questions.

I see from your opening arguments:

* "experience was mostly pleasing so far"

* "define a standard file layout cross-repo tools"

* "allow anyone curious to quickly get started with D development by cloning a single repository"

* Pointer to https://github.com/Dicebot/TestDlangAggregated/blob/master/README.md. Document shows how starting with the unified repository is easy.

There are quite a few other questions to answer:

* What's going to happen with the commit history for our current projects?

* How about the pull requests history?

* What are the changes in workflow compared to the current situation?

* What tasks will be easier?

* What tasks will be more difficult?

And probably more questions I don't even know what they are. FWIW Martin Nowak is a key person to convince of the advantages of the change.

My current perception is:

- I have a simple workflow that I'd find difficult to assume would be radically improved. But it is possible there are conveniences I'm not anticipating.

- The "getting started" advantage can be achieved on top of our current layout with tactical tools such as documentation and tools/update.sh. There's work there, of course.

- I noticed people who contribute to dmd, druntime, and phobos are relatively specialized, i.e. Kenji seldom gets into phobos, H.S. Teoh seldom gets into dmd etc. That does seem to be an argument in favor of the current modularity. Furthermore they seem to have little friction getting into these projects if they do want to.

Probably the main question is whether tooling with our layout is just fine.


Andrei

On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
> * What's going to happen with the commit history for our current projects?
>
> * How about the pull requests history?

If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.

On Wednesday, 11 February 2015 at 16:30:21 UTC, Vladimir Panteleev wrote:
> On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
>> * What's going to happen with the commit history for our current projects?
>>
>> * How about the pull requests history?
>
> If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.

I would like to add that, however, it might be worth considering moving everything to a single repository at the same time as the switch to DDMD. DDMD by itself is a big change, so aggregating other changes with big wolkflow impact (but net benefit in the long run) would make sense.

On 2/11/15 8:30 AM, Vladimir Panteleev wrote:
> On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
>> * What's going to happen with the commit history for our current
>> projects?
>>
>> * How about the pull requests history?
>
> If you have to ask this question, there's clearly a big communication
> gap. This is not an overhaul of existing repositories or processes. The
> answer to both is "nothing", and I don't think anyone is seriously
> considering a change that would invalidate either.

Can't be "nothing" - there will be something. E.g. the commit history of the new repo will be a merge of the histories of the individual projects. Is that right? -- Andrei

On Wednesday, 11 February 2015 at 16:37:29 UTC, Andrei Alexandrescu wrote:
> On 2/11/15 8:30 AM, Vladimir Panteleev wrote:
>> On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
>>> * What's going to happen with the commit history for our current
>>> projects?
>>>
>>> * How about the pull requests history?
>>
>> If you have to ask this question, there's clearly a big communication
>> gap. This is not an overhaul of existing repositories or processes. The
>> answer to both is "nothing", and I don't think anyone is seriously
>> considering a change that would invalidate either.
>
> Can't be "nothing" - there will be something. E.g. the commit history of the new repo will be a merge of the histories of the individual projects. Is that right? -- Andrei

No. To clarify, the new repo is not a replacement of the existing ones. It is an additional meta-repository, which, when cloned with --recursive, gets all the other ones.

On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
> On 2/11/15 5:48 AM, Dicebot wrote:
>> There seems to be a weird miscommunication here. I have asked your
>> opinion about this specific proposal - does it seem useful to you, would
>> you be willing to endorse it as official starting point for D
>> development etc.
>
> Problem is I don't know. That's why I submitted that task https://issues.dlang.org/show_bug.cgi?id=11792 "Investigate...". I'm not a git expert so I don't have answers to a bunch of questions.

That is perfectly fine - I can't guess what are questions are not clear without some non-expert feedback. It would be weird to do anything like that without ensuring you understand the rationale behind proposal.

Your list of questions was very insightful. I will relevant information to readme once it is nailed down in this discussion.

> * What's going to happen with the commit history for our current projects?

> * How about the pull requests history?

2 x "nothing changes". Important rationale I had in mind when choosing this specific layout is to make it purely additive change, without breaking anything in established development habits. Goal is to formalize existing working conventions into something that is stronger than convention,

> * What are the changes in workflow compared to the current situation?

No mandatory changes - existing developers can keep their habits. In the long term I'd like to move makefile targets that make assumptions about external repos (like dlang.org phobos docs generation) into aggregated repos - but even that is optional and will happen only if no one objects.

> * What tasks will be easier?

Getting working set of git master tools from scratch will be considerably easier.

git clone git@github.com:D-Programming-Language:dlang.git
cd dlang
./dlang.d update
./dlang.d build
# all done, just add ./bin to PATH and get all stuff
# available : dmd-dev, dub-dev, docs and whatever we add later
# same on all platforms

vs

mkdir dlang; cd dlang
git clone git@github.com:D-Programming-Language:dmd.git
git clone git@github.com:D-Programming-Language:druntime.git
git clone git@github.com:D-Programming-Language:phobos.git
git clone git@github.com:D-Programming-Language:dlang.org.git
git clone git@github.com:D-Programming-Language:tools.git
git clone git@github.com:D-Programming-Language:dub.git
# more and more
cd dmd
make -f posix.mak; cd ..
cd .druntime
make -f posix.mak; cd ..
# repeat something like that for each repo. sometimes different commands
# and for Windows entire flow is different
install -m 655 ./dmd/src/dmd /usr/local/bin/dmd-dev
# I am not even sure I haven't missed anything at this point

http://github.com/D-Programming-Language/installer contains some of needed automation but it misses important "cross-platform development uniformity" bit.

> * What tasks will be more difficult?

Small added effort for release manager to update submodules in meta-repo upon new releases. Can't really imagine anything else right now.

> And probably more questions I don't even know what they are. FWIW Martin Nowak is a key person to convince of the advantages of the change.

It will be next step. No point in discussing smaller details with Martin if I can't communicate general concept to you first.

> - The "getting started" advantage can be achieved on top of our current layout with tactical tools such as documentation and tools/update.sh. There's work there, of course.

Consider this whole proposal as "tools/update.sh done right". It has similar goal but eliminations all possible conventions (which are inherent points of failure) and demands cross-platfrom uniformity as mandatory.

> - I noticed people who contribute to dmd, druntime, and phobos are relatively specialized, i.e. Kenji seldom gets into phobos, H.S. Teoh seldom gets into dmd etc. That does seem to be an argument in favor of the current modularity. Furthermore they seem to have little friction getting into these projects if they do want to.

While I was regular Phobos reviewer my attention was focused there too. But I still had to build latest dmd to test changes, build latest dlang.org to check documentation updated and struggle each time proposed changes fail only on Windows for unclear reason.

> Probably the main question is whether tooling with our layout is just fine.

Please ask more questions if I have not explained something in good enough details.

On Wed, 11 Feb 2015 14:32:59 +0000, weaselcat wrote:

> I see it as quite a shame that people repeatedly say they actively avoid using classes in D in favor of structs where possible, until forced to use classes.

it has nothing with GC per se, i just don't like the concept. not epsecially D classes, but the whole C++-inspired thing (yes, i know that it wasn't C++ invention; yet it's C++ which popularized it). current OOP is overrated. and real smalltalk-like OOP is not very vell suitable for static typed languages.

i'm still slowly developing a BlackBox-like system, though, that is fully based on classes and modules. yet i don't want to develop it too far before DDMD arrives. and i don't have a codegen (alas, this problem seems unsolvable).