On Friday, 22 August 2014 at 17:06:31 UTC, Walter Bright wrote:
> On 8/22/2014 1:18 AM, Daniel Murphy wrote:
>> There are two reason it's not better documented:
>> 1. I hate writing documentation.  I really really hate it.
>
> Join the club :-)
>
>> 2. These features are rather difficult to use, and I don't want people to think
>> they can just plug-and-play.  I've spent a lot of time fighting compiler
>> alignment bugs, which are their own special kind of hell.  Many of those issues
>> have been resolved now, but only in the areas that ddmd actually exercises.
>
> Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us.

LOL! That's a hilarious comment! :)

On 8/22/2014 11:33 AM, Andrei Alexandrescu via Digitalmars-d-announce wrote:
> On 8/22/14, 10:05 AM, John Colvin wrote:
>> As I'm sure has been mentioned elsewhere, the website changes should be
>> part of the release process, not an afterthought.
>
> Agreed. Who would like to volunteer being our webmaster? We'll discuss
> with our admin to give push rights. -- Andrei

cronjob that does a git pull, and then everyone with pull permissions can keep the website updated.

On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote:
> 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play.  I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell.  Many of those issues have been resolved now, but only in the areas that ddmd actually exercises.

Do you suggest that C++ interfaces should be written by the compiler team?

On 8/23/14, 3:33 AM, Andrei Alexandrescu wrote:
> On 8/22/14, 10:05 AM, John Colvin wrote:
>> As I'm sure has been mentioned elsewhere, the website changes should be
>> part of the release process, not an afterthought.
>
> Agreed. Who would like to volunteer being our webmaster? We'll discuss
> with our admin to give push rights. -- Andrei
>

As I mentioned in an earlier post in this thread, I need access. I did the update for every beta/RC. This one was not an oversight, I intentionally did not update the page. Given the right to push the update, I will, But I'm not going to sit around creating pull requests for one a line delete or one character edit and the wait 24hour+ for it to be published before I can proceed with what I'm doing.

Then again, if that's required is a cronjob as Brad has suggested, then I guess the problem is solved.

"Walter Bright"  wrote in message news:lt7tan$24ei$1@digitalmars.com...

> > 1. I hate writing documentation.  I really really hate it.
> Join the club :-)

=)

> Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us.

I don't really mind, for some reason I enjoy tracking down wrong-code bugs. I just don't want everyone to think it'll be easy to plug in their favourite C++ library. 

"Kagamin"  wrote in message news:ujtkjzyvjhtvmcvjhgqb@forum.dlang.org...

> On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote:
> > 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play.  I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell.  Many of those issues have been resolved now, but only in the areas that ddmd actually exercises.
>
> Do you suggest that C++ interfaces should be written by the compiler team?

I'm just saying you need a fairly good knowledge of the low-level workings on C++ and D, especially if something goes wrong.  One example I hit, is that on windows if you had overloaded virtual functions, they would be inserted into the vtable backwards.  These parts of the compiler are not very well tested, so if you're not comfortable debugging this sort of thing it might be better to wait until extern(C++) has seen heavier use. 

On Friday, 22 August 2014 at 08:23:39 UTC, Daniel Murphy wrote:
>
> It works for ddmd's array.d/array.h at least, although it's not very maintenance friendly.  I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation?

What's the motivation for embedding these things in the d runtime?

Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...?

I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad. This makes the language coupled to those platforms and less general purpose like C and C++.

Mike

"Mike"  wrote in message news:sdrjfagsayomsngmeywp@forum.dlang.org...

> What's the motivation for embedding these things in the d runtime?

Make them available.

> Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...?

I don't see how.

> I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad.

Language features (gc, profiler, etc), OS bindings, C stdlib bindings.  C++ bindings aren't a big leap from there.

I think druntime started off including OS and stdlib bindings because it needed to use them internally, and it made more sense to expose them publically instead of adding dependencies or duplicating them.

> This makes the language coupled to those platforms and less general purpose like C and C++.

I disagree.  D does not depend on C++ being available, but druntime should provide bindings if possible.  Depending on the C runtime is not a problem, because realistically you will either have a C runtime available for your platform, or be on a restricted platform where you will need to define your own D runtime, and can choose which parts of the C runtime to include. 

On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message news:sdrjfagsayomsngmeywp@forum.dlang.org...
>
>> What's the motivation for embedding these things in the d runtime?
>
> Make them available.
>
>> Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...?
>
> I don't see how.

The C standard library and C++ standard library are not part of D-the-language.  D would even be better served by putting these features in phobos as std.stdc and std.stdcpp.  This would make them just as conveniently available to users, and reduce the coupling between the language and the platform.

>> I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad.
>
> Language features (gc, profiler, etc), OS bindings, C stdlib bindings.  C++ bindings aren't a big leap from there.
>
> I think druntime started off including OS and stdlib bindings because it needed to use them internally, and it made more sense to expose them publically instead of adding dependencies or duplicating them.

I think this is what makes issue 11666[1] so difficult and controversial.  The features of the C std lib that are needed by the D runtime are not many, and could be re-implemented in D. The OS bindings needed to implement the D runtime could be internal and moved to a separate folder as proposed in the spirit of 11666.  Public OS bindings could be put in std.linux, std.windows, etc... along with std.stdc and std.stdcpp.

It might be expeditious to just wrap and link, but I argue that D would be more appealing as a language (rather than a framework) if this wasn't the case.

>> This makes the language coupled to those platforms and less general purpose like C and C++.
>
> I disagree.  D does not depend on C++ being available, but druntime should provide bindings if possible.  Depending on the C runtime is not a problem, because realistically you will either have a C runtime available for your platform, or be on a restricted platform where you will need to define your own D runtime, and can choose which parts of the C runtime to include.

I concede this is true for the vast majority of systems out there, but it makes D an applications programming framework, not a systems programming language.

I politely ask those pursuing core.stdcpp to reconsider and look further in the future.  Please think beyond desktop and server application programming.  Consider what D could be used for, not just what it is currently used for, and darken the line between the language and the platform.  Make it a more of a language, and less of a framework.

Mike

[1] https://issues.dlang.org/show_bug.cgi?id=11666

On 8/25/2014 11:12 PM, Mike wrote:
> The C standard library and C++ standard library are not part of D-the-language.
> D would even be better served by putting these features in phobos as std.stdc
> and std.stdcpp.  This would make them just as conveniently available to users,
> and reduce the coupling between the language and the platform.

It's beginning to look more and more like an stdcpp is achievable.

The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though.

It also means that implementing stdcpp is going to require someone who is very willing to go spelunking around the underbelly of C++ ::std:: and understand it, which is a tall order.