On Tuesday, 10 February 2015 at 21:48:58 UTC, Andrei Alexandrescu
wrote:
> On 2/10/15 1:45 PM, Luc Bourhis wrote:
>> On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
>>> Idea is to create an aggregated repository as part of
>>> D-Programming-Language organization which will include other existing
>>> ones as a submodules
>>
>> Imho, git subtree would be a better idea
>
> That's exactly why I asked for a real investigation that discusses pros, cons, cost, benefits, resulting context, alternatives - as opposed to "well let's do it". -- Andrei

Submitting an implementation for a proposal is a valid way to
initiate discussion, and enables practical evaluation of one
solution.

On Tuesday, 10 February 2015 at 22:07:50 UTC, Ola Fosheim Grøstad wrote:
> But when the project becomes big and it is difficult to perceive changes that are significant I suppose many will feel that contributions won't matter, because the context is too large. The website was small enough and contributions are visible... so people chimed in.

This is of course some of the dynamics in:

http://en.wikipedia.org/wiki/Tragedy_of_the_commons

But you can counter it by breaking up into smaller units, e.g.

http://en.wikipedia.org/wiki/Adopt_a_Highway

> It is a delicate matter. Yes, spreading over less important issues is harmful for focusing on core ones. But the same time having many small issues unresolved harms the contribution culture as those keep annoying people over and over again.

Excellence can come in part from getting many small things right (or at least just a little bit better) that most people think don't matter.  I think Jobs was overrated compared to the technical people that made everything possible (and not just the ones at Apple), but his unreasonableness about not putting up with little things that irked him as a discerning judge did pay off for the user.  A language ecosystem is not a consumer product, and an open source project is not a commercial venture; but perhaps it's worth bearing in mind whilst also wanting to make sure effort is marshalled towards things with demonstrably high payoffs.  A difficult balance.

> In this specific case I didn't take go at this because I was bored and wanted to do _something_. It was because problem with lack of reliable standard layout kept appearing every time we wanted to improve build tools and release automation. It was because I was annoyed that I still can't test Phobos pull requests on Windows machine even despite getting one - because setting up a dev environment is just too different between platforms.

A certain renowned language designer once said that he found that working on projects he found personally important tended to pay off in the end, even if others couldn't see it in the beginning.  That's probably not true of everyone, but maybe Dicebot isn't everyone.

An economist I once knew said that entrepreneurship happens in the interstices of structure, because it is often hard to demonstrate the payoff in tangible terms...


>> Yet we do have matters that are important and urgent. We want to improve Phobos' take on memory allocation. Yet not one soul is working on RefCounted. Few know even what needs to be done of it. Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?

What needs to be done?

On Tuesday, 10 February 2015 at 17:47:59 UTC, Andrei Alexandrescu wrote:
> On 2/10/15 9:44 AM, weaselcat wrote:
>> Again I apologize for the briefness, I'll try to reply to this later
>> with better details.
>
> Much appreciated, thanks. -- Andrei

To continue from earlier,

Once again, my POV is that from a *user* of D, not a *developer.* I realize that a solid 9 out of 10 of the people on the newsgroup actively contribute to D and I don't want to offend anyone : ).

I was just using RefCounted!T as one example of a major headache I've had with D. To follow up upon earlier,
https://issues.dlang.org/show_bug.cgi?id=2757

This issue was filed in 2009 and succinctly covers why someone might need deterministic resource management(i.e - RAII.) 3 months ago it was marked WONTFIX with a statement to just use Refcounted. Great. Except the issue wasn't fixed because Refcounted has serious issues and IMO it shouldn't have been closed. I'd harp on this - but a feature request for it already exists. https://issues.dlang.org/show_bug.cgi?id=13983
Not just one either... https://issues.dlang.org/show_bug.cgi?id=13972 https://issues.dlang.org/show_bug.cgi?id=9998 (2013) (I don't think any of them address that refcounted is unusable on classes, abandon polymorphism all ye who attempt to work around the GC.)

So pretty much the only way to handle resources that require cleanup is to use a struct. Using the destructor of an object for... well, nearly anything is undefined AFAICT. I have a fun game, walk up to a random person at the next CPPcon and tell them that they're no longer allowed to use destructors to manage resources and see what kind of face they make ;)

At this point I start to realize that _most_ of the code I'm attempting to port requires this type of management. Suddenly I feel like I've been thrown a few decades in the past and get to use C with fancy semantics like slicing. The one thing the language has basically been designed around is completely unusable to me because I can't rely on the GC's non-deterministic behavior.

I'd love the GC if it could actually _manage_ my garbage for me, but instead I feel like D has delegated me to the position of garbage collector in a much more serious way than C++ _ever_ has... well, C++11 and forward anyways.

FYI, this thread has a great discussion on these issues. http://forum.dlang.org/thread/20140430231745.GA1125@quickfur.ath.cx?page=3#post-bqweskwediwlijuzfdts:40forum.dlang.org

I'm sure I'll get a response from ketmar( ;-) ) or another D superuser who will scoff at my issues and how they know how to work around the warts in D by using arcane hacks and custom patches... but honestly I don't think I'm the first person to make these sort of complaints. Hell, the blog that started two(? one?) of the bug requests linked above mentioned the same issue.

I made these two posts not to cry about the language, but to say "Hey, D is kind of really lacking here!" I'd love to just submit a PR, but it is above my paygrade to fix a major feature like RefCounted.

I'm sorry if this is off-topic, I did not mean to derail your thread Dicebot. I just wanted to share my experience of trying to ease into D as someone who can't just open up phobos and begin hacking away enhancements like most of the people here.

I hope this was the sort of reply you were looking for, Andrei.

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 making the right decisions in making any changes to it.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

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.

but hey, do you need classes at all? structs works too, you can have pointers to functions inside, you can simulate inheritance with `alias this`, and you can use `RefCounted!`. and there is mixin magic to write nice initializers. (sorry, i just can't stand the temptation!)

On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
> 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
> making the right decisions in making any changes to it.

I also think it doesn't look like a big job, but I didn't see any current activity on the subject and my own immediate priorities are elsewhere, hence the simple one-line PR as a stop-gap measure.

On Tuesday, 10 February 2015 at 22:12:41 UTC, Vladimir Panteleev wrote:
> On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote:
>> On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
>>> Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules
>>
>> Imho, git subtree would be a better idea
>
> I don't think so.
>
> What are the advantages?

With subtree, one has a unified working directory from which one can straightforwardly make commits for each components. So if one makes a change on phobos that relies on a change on dmd, both changes can easily be made, committed and then pushed. With submodule, this is so cumbersome that it would requires some dedicated scripts.

>One big disadvantage that I see is that you can't create pull
> requests to the original repos from subtrees.

You would create pull separate pull requests for the dmd repository, the phobos directory, etc. You mean you want to be able to do pull request from the master repository? Again, it seems to me this is not going to be intuitive at all with submodules.

On Wednesday, 11 February 2015 at 13:33:29 UTC, Luc Bourhis wrote:
> On Tuesday, 10 February 2015 at 22:12:41 UTC, Vladimir Panteleev wrote:
>> On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote:
>>> On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
>>>> Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules
>>>
>>> Imho, git subtree would be a better idea
>>
>> I don't think so.
>>
>> What are the advantages?
>
> With subtree, one has a unified working directory from which one can straightforwardly make commits for each components. So if one makes a change on phobos that relies on a change on dmd, both changes can easily be made, committed and then pushed. With submodule, this is so cumbersome that it would requires some dedicated scripts.

Switching actual development to aggregated is not considered, because it is much more intrusive change. I have considered subtree and rejected that approach exactly because it does not actually track remotes for aggregated projects that way.

My proposal does not change _anything_ in existing development process and this important. It simply adds extra layer of convenience on top.

It is also important that changes to affect multiple repos at the same time are relatively rare and optimizing layout for those does not seem practical.

>>One big disadvantage that I see is that you can't create pull
>> requests to the original repos from subtrees.
>
> You would create pull separate pull requests for the dmd repository, the phobos directory, etc. You mean you want to be able to do pull request from the master repository? Again, it seems to me this is not going to be intuitive at all with submodules.

No so far one complained about it being counter-intuitive, quite the contrary. Complicated part is configuring and testing everything, not submitting pull requests - latter seems to work perfectly as it is now.

On Tuesday, 10 February 2015 at 17:04:36 UTC, Andrei Alexandrescu wrote:
> On 2/9/15 11:17 PM, Dicebot wrote:
>> I do what I feel needs to be done. You are free either reject or accept
>> it. But please don't tell me how I should manage my own spare time. If
>> you want cultural change - lead by example.
>
> I only replied because you explicitly asked for my opinion, under the assumption it would be discussed civilly even if it is not aligned with yours.
>
> Andrei

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. Instead I got verbose explanation about my attitude being wrong and how other areas are more important to work on. Thus it wasn't on point at all.

By rejecting this you won't make me work on other things that _you_ consider more important - it will simply make me reconsider this project as private one and not keep in mind potential upstream inclusion.

May I suggest you to do some research on open-source project management and related topics? It feels like there is a huge mismatch between how you expect things to work and how those happen to work in practice. Such misplaced expectations can do a lot of harm for project leadership.