On 11/8/2013 3:33 PM, deadalnix wrote:
> Getting a build master :D

We clearly need a better title!

On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:
> I made a wiki page for that.
> Please discuss, improve and prioritize.
> http://wiki.dlang.org/Agenda

Update the processes so that there's a public beta release rather than only an "insider" beta release to better smooth things out. Right now 2.064 should be tagged as the latest public beta version with 2.063 as the current stable release.

--rt

runtime loading of shared libraries on OSX, so that it works as on linux I see b/10440 fixed in changelog, however does that mean it should work as safely as on linux? (both runtime and nonruntime libs)

Also, IIRC, I thought 2.064 introduced support for loading D shared libs safely from D, but see no mention of this in changelog?



On Fri, Nov 8, 2013 at 4:36 PM, Rob T <alanb@ucora.com> wrote:

> On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:
>
>> I made a wiki page for that.
>> Please discuss, improve and prioritize.
>> http://wiki.dlang.org/Agenda
>>
>
> Update the processes so that there's a public beta release rather than only an "insider" beta release to better smooth things out. Right now 2.064 should be tagged as the latest public beta version with 2.063 as the current stable release.
>
> --rt
>

On Saturday, 9 November 2013 at 00:31:59 UTC, Walter Bright wrote:
> On 11/8/2013 3:01 PM, Brad Roberts wrote:
>> I strongly urge the release timing to be a max of 2 months from now, not 5.  I'd
>> prefer getting back to monthly if we can, but that's probably overly optimistic
>> based on the way we've been doing things.

I choose march because ~4 month is already an improvement.
Anything below 3 month seems unrealistically ambitious to me atm.

>
> It can be done if we get an automated release process (hint, hint!).

Indeed this is an important topic. We need a few discussions and some coordinated effort to get there.

On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:
> runtime loading of shared libraries on OSX, so that it works as on linux
> I see b/10440 fixed in changelog, however does that mean it should work as
> safely as on linux? (both runtime and nonruntime libs)

I'm focusing on full linux support for now. Other platforms will follow.
Anything that currently works (Windows DLLs) is fairly broken.

> Also, IIRC, I thought 2.064 introduced support for loading D shared libs
> safely from D, but see no mention of this in changelog?
>
We added the necessary low-level bits to support this, but quite a lot is still missing.
https://github.com/D-Programming-Language/druntime/pull/617
https://github.com/D-Programming-Language/druntime/pull/658

On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:
> I made a wiki page for that.
> Please discuss, improve and prioritize.
> http://wiki.dlang.org/Agenda

Can we add this page to the wiki homepage, for example in "Core Development" section? Probably, more people will see it.

Added language enhancements from my working list.

Kenji Hara


2013/11/9 Martin Nowak <code@dawg.eu>

> I made a wiki page for that.
> Please discuss, improve and prioritize.
> http://wiki.dlang.org/Agenda
>

On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:

> runtime loading of shared libraries on OSX, so that it works as on linux
> I see b/10440 fixed in changelog, however does that mean it should work as
> safely as on linux? (both runtime and nonruntime libs)

Unfortunately no. I think the biggest obstacle is TLS. DMD emulates TLS on Mac OS X, which doesn't really work with dynamic libraries. It didn't exist natively on Mac OS X when DMD for D2 was ported to Mac OS X. I guess that best option is that DMD start to use native TLS. That would mean we need to drop support for Mac OS X Snow Leopard (10.6). Unless we move the part of the dynamic linker that handles TLS to druntime, which I think is technially possible.

Except from that I think it might be easier to implement support for dynamic libraries on Mac OS X. The dynamic linker on Mac OS X has a much broader API than on Linux. We can use more of the existing functions there.

--
/Jacob Carlborg

On 2013-11-09 07:47, Martin Nowak wrote:

> I choose march because ~4 month is already an improvement.
> Anything below 3 month seems unrealistically ambitious to me atm.

It depends on what we want to achieve. Either we set the agenda after a release schedule. Or we do it the other way around. I know Iain has been complaining when releases are taking longer time.

BTW, do people in general have more or less time working on D during the Christmas? I know I will have more time.

-- 
/Jacob Carlborg

Are there any plans for adding compile-time checking or recursive
data types to std.variant's Algebraic? I think algebraic data
types are important and the current implementation is not
suitable to solve a good portion of problems that the intended
implementation could.

Could this be a possible goal for 2.065? If not, are we lacking
demand? Lacking someone willing to work on it?