Thanks everyone and in particular Kenji for helping to get 2.069.0 out the door. We're late by over a week b/c it took us a while to fix Issue 15027.

# Let's discuss the main goals for the next release:

Again I'd like to see 313&314 being fixed b/c any delay on that makes it more painful to fix later on. As this change has a big impact we all need to agree on the direction and should start the work as early as possible in the next release cycle. https://trello.com/c/YoAFvV5n/6-313-314

A lot of GC work remains and I'd like to get back on that in 2-3 weeks. https://trello.com/c/Xp44NwHG/87-ttas-spinlock-for-gc https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc https://trello.com/c/Dsdxd1r3/56-ptr-data-section https://trello.com/c/0WxZP9KL/11-freelist-for-large-objects

# Plans for the next sprint:

For the next 2 weeks I want to finish the work on slist_reset (https://trello.com/c/qMjMxduV/98-optimize-slist-reset) which speeds up static library compilation by about 20%. Hope that only a small OSX issue remains.

Other than that I want to focus on finishing the smart refs implementation (https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation). I've decided to do this in the form of a new std.experimental module rather than breaking any of the existing std.typecons implementations. We're still in need of a good name for that module.

planned feature list:

- RC/WeakRef/Unique
- full support for polymorphism (and RC for interfaces)
- only shared(RC) uses atomic ref counting
- full attribute inference
- support for allocators (defaulting Mallocator)
- message passing for Unique (if the payload doesn't alias anything mutable)

...your plans...

## Side note

We added good D support for Heroku [¹] and submitted a D .gitignore template to github [²].

[¹]: https://github.com/MartinNowak/heroku-buildpack-d [²]: https://github.com/github/gitignore/pull/1676

If you see a project w/o D support or some protocol w/o a D client, consider adding it. It's often little work but greatly improves the D usage experience.

-Martin

On 10/27/2015 06:15 AM, Martin Nowak via dmd-internals wrote:
> Again I'd like to see 313&314 being fixed b/c any delay on that makes it
> more painful to fix later on. As this change has a big impact we all
> need to agree on the direction and should start the work as early as
> possible in the next release cycle.
> https://trello.com/c/YoAFvV5n/6-313-314

I'd very much want to get Walter's 100% approval on this. We seem to have a growing complexity problem in that overly complicated solutions are being pushed that nobody but their author understands and reviews properly. They don't get enough review and change the language in intractable ways.

Same is happening with the library, as I mentioned discussing the DirEntry regression aftermath. (Another historical example: the @trusted morass.) Mechanical, large, non-scalable changes are pushed following a too literal interpretation of desirable points (such as "don't break backwards compatibility") yet at the cost of long-term crucial goals, such as preserving the spirit of the language and a sense and sensibility in its standard library.

Please run absolutely all important changes of the standard library by me personally. Email me - I address all of my emails, albeit with delays. If urgent email me again. I'm also on skype at andrei.tudor.alexandrescu. Thanks.

Also, I'm thinking we should pass all new names through std.experimental - thoughts? For a random example: https://github.com/D-Programming-Language/phobos/pull/3765. Looks like a sensible addition, but I'd want us all to get disciplined about vetting additions before committing to maintaining them forever.

> A lot of GC work remains and I'd like to get back on that in 2-3 weeks.
> https://trello.com/c/Xp44NwHG/87-ttas-spinlock-for-gc
> https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc
> https://trello.com/c/Dsdxd1r3/56-ptr-data-section
> https://trello.com/c/0WxZP9KL/11-freelist-for-large-objects

These look great. Also, there's a lot of stuff of interest in std.experimental.allocator that I'd want to integrate with the GC. To that end, we need to make the GC more statically modular so we get to plug in various allocation strategies. Do you have an image of what can be done for better integration?

> # Plans for the next sprint:
>
> For the next 2 weeks I want to finish the work on slist_reset
> (https://trello.com/c/qMjMxduV/98-optimize-slist-reset) which speeds up
> static library compilation by about 20%. Hope that only a small OSX
> issue remains.

Awesome. BTW what's the status of dynamic libraries on the three major OSs? I'm sorry, that topic has been out of my mind for a while so I lost contact with the matters.

> Other than that I want to focus on finishing the smart refs
> implementation
> (https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation). I've
> decided to do this in the form of a new std.experimental module rather
> than breaking any of the existing std.typecons implementations. We're
> still in need of a good name for that module.
>
> planned feature list:
>
> - RC/WeakRef/Unique
> - full support for polymorphism (and RC for interfaces)
> - only shared(RC) uses atomic ref counting
> - full attribute inference
> - support for allocators (defaulting Mallocator)
> - message passing for Unique (if the payload doesn't alias anything mutable)
>
> ...your plans...

Oddly enough I want to dissuade you from doing RC - per my post "Safe reference counting cannot be implemented as a library" it's impossible to make library-level RC safe, which decreases its interest dramatically. We plan to do language-level reference counting, which, if we succeed, would obviate any RC library for classes.

However, working on uniqueness is great! We'll either see how far we can get within the current language, or figure the minimal language additions needed to make it work.

For message passing, TDPL mentions a UniqueArray that can be passed across threads but has not been yet implemented.


Thanks,

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Oct 27, 2015, at 10:58 PM, Andrei Alexandrescu via dmd-internals <dmd-internals@puremagic.com> wrote:

Awesome. BTW what's the status of dynamic libraries on the three major OSs? I'm sorry, that topic has been out of my mind for a while so I lost contact with the matters.

Linux and FreeBSD are supported. OS X is officially not supported, native TLS is a blocker. I'm not sure about Windows.

--
/Jacob Carlborg

On 27 Oct 2015, at 23:45, Andrei Alexandrescu via dmd-internals wrote:
> I'd very much want to get Walter's 100% approval on this. We seem to have a growing complexity problem in that overly complicated solutions are being pushed that nobody but their author understands and reviews properly. They don't get enough review and change the language in intractable ways.

I'd claim that this change does exactly the opposite; making the language less complex by fixing inscrutable semantics. There might be simpler ways to fix the issue (see previous PRs), but you guys (probably mostly Walter) didn't like them because of its "breaking" nature (even though some of those broken pieces of code were questionable to begin with).

> Awesome. BTW what's the status of dynamic libraries on the three major OSs? I'm sorry, that topic has been out of my mind for a while so I lost contact with the matters.

DMD supports them on Linux and FreeBSD, LDC currently on Linux only (as the most recent release is based 2.067 still), and GDC doers not support them properly at all. As for Windows, I suppose it depends on who you ask, but DLLs definitely don't work as seamlessly as on the Posixen (cf. the export discussion).

 — David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/28/2015 03:48 AM, Jacob Carlborg wrote:
> On Oct 27, 2015, at 10:58 PM, Andrei Alexandrescu via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>
>> Awesome. BTW what's the status of dynamic libraries on the three major
>> OSs? I'm sorry, that topic has been out of my mind for a while so I lost
>> contact with the matters.
>
> Linux and FreeBSD are supported. OS X is officially not supported,
> native TLS is a blocker. I'm not sure about Windows.

Thanks. Do we have a tracker issue for OSX and anyone working on it? -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 28 Oct 2015, at 14:03, Andrei Alexandrescu via dmd-internals wrote:
> On 10/28/2015 03:48 AM, Jacob Carlborg wrote:
>> Linux and FreeBSD are supported. OS X is officially not supported,
>> native TLS is a blocker. I'm not sure about Windows.
>
> Thanks. Do we have a tracker issue for OSX and anyone working on it? -- Andrei

It would be pretty straightforward to get working on LDC/OS X – basically just go through our (well, Martin did most of the work) implementation for Linux and adapt it, using the dyld source code for reference [1]. I don't think anybody is working on it right now, though (Dan, maybe?).

For DMD, you are going to need the help of a person who is willing to deal with the backend part of the TLS implementation first. You can the use the same solution as for LDC.

 — David


[1] You might need to use some "private" functions to get the enumeration of sections working in a way that does not lead to a crash when the shared library is unloaded.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/28/2015 08:11 AM, David Nadlinger wrote:
> On 28 Oct 2015, at 14:03, Andrei Alexandrescu via dmd-internals wrote:
>> On 10/28/2015 03:48 AM, Jacob Carlborg wrote:
>>> Linux and FreeBSD are supported. OS X is officially not supported,
>>> native TLS is a blocker. I'm not sure about Windows.
>>
>> Thanks. Do we have a tracker issue for OSX and anyone working on it?
>> -- Andrei
>
> It would be pretty straightforward to get working on LDC/OS X
> – basically just go through our (well, Martin did most of the work)
> implementation for Linux and adapt it, using the dyld source code for
> reference [1]. I don't think anybody is working on it right now, though
> (Dan, maybe?).

Thanks, please keep us posted.

> For DMD, you are going to need the help of a person who is willing to
> deal with the backend part of the TLS implementation first. You can the
> use the same solution as for LDC.

I'll ask Walter. So are you referring to the existing Linux LDC implementation, or the not-yet-existing OSX LDC implementation you sketched above?


Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 28 Oct 2015, at 16:18, Andrei Alexandrescu wrote:
> On 10/28/2015 08:11 AM, David Nadlinger wrote:
>> For DMD, you are going to need the help of a person who is willing to
>> deal with the backend part of the TLS implementation first. You can the
>> use the same solution as for LDC.
>
> I'll ask Walter. So are you referring to the existing Linux LDC implementation, or the not-yet-existing OSX LDC implementation you sketched above?

What I was trying to say is that if somebody not familiar with the DMD backend wanted to use OS X shared libraries, I'd point them towards LDC right now. After it works there, the same code can be used for DMD too (it's strictly more work to implement it there because of the TLS implementation). And to get it to work on LDC, the non-ELF-specific parts of the Linux/FreeBSD implementation can be reused.

 — David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On 28 okt 2015, at 15:18, Andrei Alexandrescu via dmd-internals <dmd-internals@puremagic.com> wrote: On 10/28/2015 08:11 AM, David Nadlinger wrote:
>> For DMD, you are going to need the help of a person who is willing to deal with the backend part of the TLS implementation first. You can the use the same solution as for LDC.
> 
> I'll ask Walter. So are you referring to the existing Linux LDC implementation, or the not-yet-existing OSX LDC implementation you sketched above?

I think he’s referring to the TLS implementation. LDC already supports native TLS on OS X, but not dynamic libraries.

-- 
/Jacob Carlborg
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/28/2015 01:03 PM, Andrei Alexandrescu via dmd-internals wrote:
> Thanks. Do we have a tracker issue for OSX and anyone working on it? -- Andrei

We're a bit stuck with using dyld callbacks and need init/fini hooks
like for ELF.
https://issues.dlang.org/show_bug.cgi?id=15060#c4

I worked a bit with Benjamin Thaut on Windows DLLs which is currently
stuck b/c of broken export. Haven't heard from him for a while, but the
latest conclusion was that export needs to become an attribute (not a
protection level).
http://wiki.dlang.org/DIP45