On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
>>
>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
>
>
> Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.

If anyone wants to help out...

I have to also juggle working on GCC and GDB. :-)

When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

A couple comments:
a) No mention of targeting increased organizational participation (academic, corporate, etc). Not trying to suggest it should or shouldn't be a goal. Just that if it is goal meaningful effort will be directed toward in H1 then it'd be worth including in the writeup.

b) More specificity in the roadmap and priorities, to the extent they are known - As a potential D adopter, it'd be useful to have better insight into where the language might be a year or two out. For example, what forms of C++ integration might be available, or if the major components of the standard library are likely to be available nogc. However, it's hard to discern this from the writeup. Perhaps in many cases it would be premature to establish such goals, but to the extent there has been concrete thought it'd be useful to write it up. This comment is similar to a number of others suggesting a preference for more concrete goals.

--Jon

On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:
> On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>>
>> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
>>>
>>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
>>
>>
>> Just out of curiosity, is getting the different compilers in sync still a
> priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
>
> If anyone wants to help out...
>
> I have to also juggle working on GCC and GDB. :-)
>
> When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...

It would be nice if keeping them in sync was a priority, I would love to use GDC so I could use GDB, but not having the latest fixes is simply not worth it. Even simple things dont work when you go back just a few versions, like in 2.066 isForwardRange is not correct and does not work properly, something as simple as that does not work. Not to mention using the new stuff like allocators.

On 29 January 2016 at 21:14, Tofu Ninja via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:
>
>> On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>>
>>>
>>> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
>>>
>>>>
>>>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
>>>>
>>>
>>>
>>> Just out of curiosity, is getting the different compilers in sync still a
>>>
>> priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
>>
>> If anyone wants to help out...
>>
>> I have to also juggle working on GCC and GDB. :-)
>>
>> When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
>>
>
> It would be nice if keeping them in sync was a priority, I would love to use GDC so I could use GDB, but not having the latest fixes is simply not worth it. Even simple things dont work when you go back just a few versions, like in 2.066 isForwardRange is not correct and does not work properly, something as simple as that does not work. Not to mention using the new stuff like allocators.
>

How much of it actually depends on the compiler though?  I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes.

On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:
> How much of it actually depends on the compiler though?  I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes.

I have no idea, I think you are probably right. But having a compiler and phobos out of sync sounds even worse than the way it is now. A better solution for me would be to just stick with a version and wait for gdc to catch up but honestly it seems like as soon as a new version comes out I hit some bug that is only fixed in the latest version, forcing me to upgrade.

For example this literally happened days ago, I am currently at 2.069 and the other day I needed to call some winapi stuff, only to realize the winapi bindings are way outdated, well guess what they are updated in 2.070. Its amazing how often I hit a problem and then find out its fixed in the next version.

On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
> In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard.

I've noticed that curated lists of libraries are popping up on github for various languages:
https://github.com/search?utf8=%E2%9C%93&q=awesome

If D gets more users maybe there would be a market for a commercial IDE with a reviewed repository with globally searchable reference documentation and cookbook recipes.

For popular languages stack overflow is pretty ok, but over time it is getting more chaotic.

Imagine an intelligent IDE that looks at the probability of a match between a cookbook recipe and what you type. A.I. templating of sorts.

> Then the line between "standard library" and other library basically disappears.

I usually prefer to download from github for commercial code and put it in my project archive. I want to check out if the library programmers are maintaining it and have enough people as well. Then I lock that version until I find a reason to upgrade.

For me automatic downloading (dub etc) fits more with hobby projects and experiments.

> While that isn't likely to happen, we could at least start promoting third party stuff more equally.

Yep, a curated list like those awesome-lists found on github would be a start.

Then write tutorials that only use libraries from that list.

> This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user.

Yeah, I find myself constantly wanting to improve on even the simplest libraries for better interaction with the kind of code the functions/objects seem to be most used with.

More of a discovery process of usability than "mathematical deduction".

On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad wrote:

>
> Yep, a curated list like those awesome-lists found on github would be a start.
>

I've got one before there were many awesome-lists: https://github.com/zhaopuming/awesome-d

On 28 Jan 2016 6:30 PM, "Ola Fosheim Grøstad via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
[snip]
>
> 4. You cannot easily fix bugs, because applications depends on the old
behaviour. So a bug fix is a breaking change. You have to deprecate and provide the same functionality under a new name instead.
>
> External libraries can avoid a lot of these issues by versioning.
Selecting between many different versions of submodules of a standard library is way too complicated.
>

This is the main problem with "batteries included".
While just providing default libraries for specific domains through dub
solves the 3rd party Isis purple have mentioned there is no way a batteries
included standard library can keep backwards compatibility and be a
pleasure to work with, for those working on it and those using it.

On 29 January 2016 at 22:29, Tofu Ninja via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:
>
>> How much of it actually depends on the compiler though?  I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes.
>>
>
> I have no idea, I think you are probably right. But having a compiler and phobos out of sync sounds even worse than the way it is now. A better solution for me would be to just stick with a version and wait for gdc to catch up but honestly it seems like as soon as a new version comes out I hit some bug that is only fixed in the latest version, forcing me to upgrade.
>
> For example this literally happened days ago, I am currently at 2.069 and the other day I needed to call some winapi stuff, only to realize the winapi bindings are way outdated, well guess what they are updated in 2.070. Its amazing how often I hit a problem and then find out its fixed in the next version.
>

I know, I've been hitting bug after bug in 2.067, and the answer has always been to backport from 2.068.  I already have backported druntime's object.d from 2.068 because 2.067's object module has drifted so far out of sync with it's hidden implementation, I couldn't build anything!  So I might as well backport the rest of the druntime library.  Nothing much has changed as it was a "bugfix" release.

Iain.

On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:
>
> I know, I've been hitting bug after bug in 2.067, and the answer has always
> been to backport from 2.068.  I already have backported druntime's object.d
> from 2.068 because 2.067's object module has drifted so far out of sync
> with it's hidden implementation, I couldn't build anything!  So I might as
> well backport the rest of the druntime library.  Nothing much has changed
> as it was a "bugfix" release.
>

The process will be complete when you've backported the entirety of 2.068.