Building Phobos yields:

std/mmfile.d(332): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.osx.sys.mman for non-POSIX extensions

What is the right fix here?


Thanks,

Andrei

On Sunday, 15 February 2015 at 21:26:27 UTC, Andrei Alexandrescu wrote:
> Building Phobos yields:
>
> std/mmfile.d(332): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.osx.sys.mman for non-POSIX extensions
>
> What is the right fix here?

Import core.sys.osx et al. instead (you might need to make sure that it takes predenence). If I remember correctly, the rationale behind the change(s) was that core.sys.posix should only have the symbols that are actually mandated by the POSIX spec to avoid confusion/portability problems.

David

On Sunday, 15 February 2015 at 21:26:27 UTC, Andrei Alexandrescu wrote:
> Building Phobos yields:
>
> std/mmfile.d(332): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.osx.sys.mman for non-POSIX extensions
>
> What is the right fix here?

The line above the faulting one is:

version(linux) import core.sys.linux.sys.mman : MAP_ANON;

I imagine the fix would be along the same line :)

version(OSX) import core.sys.osx.sys.mman : MAP_ANON;

std.mmfile is one of the legacy modules, in good need of a rewrite or overhaul.

On Sunday, 15 February 2015 at 21:32:53 UTC, David Nadlinger wrote:
> Import core.sys.osx et al. instead (you might need to make sure that it takes predenence). If I remember correctly, the rationale behind the change(s) was that core.sys.posix should only have the symbols that are actually mandated by the POSIX spec to avoid confusion/portability problems.

I'm not sure if, for the case of extensions adopted by multiple platforms, it makes sense to force users to import each platform's module. Was creating a separate module with shared POSIX extensions considered?

On 2/15/15 1:36 PM, Vladimir Panteleev wrote:
> On Sunday, 15 February 2015 at 21:26:27 UTC, Andrei Alexandrescu wrote:
>> Building Phobos yields:
>>
>> std/mmfile.d(332): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON
>> is deprecated - Please use core.sys.osx.sys.mman for non-POSIX extensions
>>
>> What is the right fix here?
>
> The line above the faulting one is:
>
> version(linux) import core.sys.linux.sys.mman : MAP_ANON;
>
> I imagine the fix would be along the same line :)
>
> version(OSX) import core.sys.osx.sys.mman : MAP_ANON;
>
> std.mmfile is one of the legacy modules, in good need of a rewrite or
> overhaul.

I agree. I think the problem here is that if this doesn't get fixed we'll release Phobos with deprecated stuff it.

That's hardly sending the right message to people about bringing their own code up to snuff.

Folks, we want to get 2.067 out the door on March 1. That's two short weeks from now. We really need all hands on deck to make this a successful release.


Thanks,

Andrei

On Sun, 15 Feb 2015 18:19:49 -0800, Andrei Alexandrescu wrote:

> Folks, we want to get 2.067 out the door on March 1. That's two short weeks from now. We really need all hands on deck to make this a successful release.

we can't. this issue, for example, was known for monthes (or, maybe, years?), yet there is no sign that it's something that MUST be fixed for release.

what i want to tell is that there is no release plan, no feature freeze before releasing, no easy accessible and automatically maintained list of release blockers and so on. there is no sense in pretending that we have that, and there is no way to force people to do it. just freese, release what we have and then make some patch releases to fix the obvious blocking (and accidentally missed) bugs, if any. make "just another release in line", with 2.068 in four-six month and so on.

On Monday, 16 February 2015 at 16:00:29 UTC, ketmar wrote:
> we can't. this issue, for example, was known for monthes (or, maybe,
> years?), yet there is no sign that it's something that MUST be fixed for
> release.
>
> what i want to tell is that there is no release plan, no feature freeze
> before releasing, no easy accessible and automatically maintained list of
> release blockers and so on. there is no sense in pretending that we have
> that, and there is no way to force people to do it. just freese, release
> what we have and then make some patch releases to fix the obvious
> blocking (and accidentally missed) bugs, if any. make "just another
> release in line", with 2.068 in four-six month and so on.

I agree.

To be brutally honest the biggest release mistakes (which seems to be getting worse lately) are D releases with outstanding regressions. That's pretty unacceptable IMHO.

On 2015-02-16 17:51, Gary Willoughby wrote:

> I agree.
>
> To be brutally honest the biggest release mistakes (which seems to be
> getting worse lately) are D releases with outstanding regressions.
> That's pretty unacceptable IMHO.

Yes, and that someone thinks we need release on a specific date, even though there is no schedule or plan to look at.

-- 
/Jacob Carlborg

On 2/16/15 12:23 PM, Jacob Carlborg wrote:
> On 2015-02-16 17:51, Gary Willoughby wrote:
>
>> I agree.
>>
>> To be brutally honest the biggest release mistakes (which seems to be
>> getting worse lately) are D releases with outstanding regressions.
>> That's pretty unacceptable IMHO.
>
> Yes, and that someone thinks we need release on a specific date, even
> though there is no schedule or plan to look at.

Martin, as our release czar you may want to publish the planned ship date. -- Andrei

On Monday, 16 February 2015 at 20:31:22 UTC, Andrei Alexandrescu wrote:
> Martin, as our release czar you may want to publish the planned ship date. -- Andrei

Isn't it already "published"?

http://dlang.org/changelog.html