• Andrei Alexandrescu (6/6) Feb 15 2015 Building Phobos yields:
• David Nadlinger (8/13) Feb 15 2015 Import core.sys.osx et al. instead (you might need to make sure
• Vladimir Panteleev (6/11) Feb 15 2015 I'm not sure if, for the case of extensions adopted by multiple
• Martin Nowak (5/9) Feb 17 2015 I'm not sure either. We try to be strict to avoid inadvertent
• Martin Nowak (2/5) Feb 17 2015 https://github.com/D-Programming-Language/druntime/pull/1176
• Andrei Alexandrescu (4/12) Feb 17 2015 I'd be okay with that. Anyhow it's important we remove the deprecation
• Vladimir Panteleev (8/13) Feb 15 2015 The line above the faulting one is:
• Andrei Alexandrescu (10/23) Feb 15 2015 I agree. I think the problem here is that if this doesn't get fixed
• ketmar (11/14) Feb 16 2015 we can't. this issue, for example, was known for monthes (or, maybe,=20
• Gary Willoughby (5/23) Feb 16 2015 I agree.
• Jacob Carlborg (5/9) Feb 16 2015 Yes, and that someone thinks we need release on a specific date, even
• Andrei Alexandrescu (3/11) Feb 16 2015 Martin, as our release czar you may want to publish the planned ship
• Vladimir Panteleev (4/6) Feb 16 2015 Isn't it already "published"?
• Jacob Carlborg (5/7) Feb 17 2015 Not the first place I would go looking for an upcoming release. It would...

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"David Nadlinger" <code klickverbot.at> writes:

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

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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?

"Martin Nowak" <code dawg.eu> writes:

On Sunday, 15 February 2015 at 21:38:17 UTC, Vladimir Panteleev 
wrote:
 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?

I'm not sure either. We try to be strict to avoid inadvertent 
porting issues, but MAP_ANON is supported on so many platforms 
that we might just leave it in posix.

"Martin Nowak" <code dawg.eu> writes:

On Tuesday, 17 February 2015 at 08:59:48 UTC, Martin Nowak wrote:
 I'm not sure either. We try to be strict to avoid inadvertent 
 porting issues, but MAP_ANON is supported on so many platforms 
 that we might just leave it in posix.

https://github.com/D-Programming-Language/druntime/pull/1176

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/17/15 12:59 AM, Martin Nowak wrote:
 On Sunday, 15 February 2015 at 21:38:17 UTC, Vladimir Panteleev wrote:
 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?

 I'm not sure either. We try to be strict to avoid inadvertent porting
 issues, but MAP_ANON is supported on so many platforms that we might
 just leave it in posix.

I'd be okay with that. Anyhow it's important we remove the deprecation 
message from Phobos itself.

Andrei

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

ketmar <ketmar ketmar.no-ip.org> writes:

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,=20
years?), yet there is no sign that it's something that MUST be fixed for=20
release.

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

"Gary Willoughby" <dev nomad.so> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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

Jacob Carlborg <doob me.com> writes:

On 2015-02-17 00:00, Vladimir Panteleev wrote:

 Isn't it already "published"?

 http://dlang.org/changelog.html

Not the first place I would go looking for an upcoming release. It would 
be better to have a proper page for a road map/plan.

-- 
/Jacob Carlborg