So, just fixed another "bug" that was using version(linux).
i.e. it worked just fine on Darwin too, if it had compiled.
What will it take for DMD to support the portable modules ?

The current situation is not very good. GDC 0.17 is missing
the std.c.linux.linux due to a slight oversight, but why is
DMD missing the std.c.unix.unix module ? Or version(Unix) ?

It's been requested (and needed) for several years now :-(


All it needs to be doing on DMD is import std.c.linux.linux,
even if it is currently being neatly autogenerated on GDC...

I'm just tired of making these dual-platform -> cross-platform
And just like "printf", this is breeding some bad D practices ?

Pretty please, add "std.c.unix.unix" and version(Unix) to DMD.
--anders

--
Elwood: Ah... what kind of music do you usually have here?
Claire: Oh we got both kinds. We got Country, and Western.

Anders F Björklund wrote:
> So, just fixed another "bug" that was using version(linux).
> i.e. it worked just fine on Darwin too, if it had compiled.
> What will it take for DMD to support the portable modules ?
> 
> The current situation is not very good. GDC 0.17 is missing
> the std.c.linux.linux due to a slight oversight, but why is
> DMD missing the std.c.unix.unix module ? Or version(Unix) ?
> 
> It's been requested (and needed) for several years now :-(
> 
> 
> All it needs to be doing on DMD is import std.c.linux.linux,
> even if it is currently being neatly autogenerated on GDC...
> 
> I'm just tired of making these dual-platform -> cross-platform
> And just like "printf", this is breeding some bad D practices ?
> 
> Pretty please, add "std.c.unix.unix" and version(Unix) to DMD.
> --anders
> 

Seconded.

> -- 
> Elwood: Ah... what kind of music do you usually have here?
> Claire: Oh we got both kinds. We got Country, and Western.

Heh, heh - great flick. Just saw it again the other day...

Dave wrote:

> Anders F Björklund wrote:
>> So, just fixed another "bug" that was using version(linux). i.e. it worked just fine on Darwin too, if it had compiled. What will it take for DMD to support the portable modules ?
>> 
>> The current situation is not very good. GDC 0.17 is missing the std.c.linux.linux due to a slight oversight, but why is DMD missing the std.c.unix.unix module ? Or version(Unix) ?
>> 
>> It's been requested (and needed) for several years now :-(
>> 
>> 
>> All it needs to be doing on DMD is import std.c.linux.linux, even if it is currently being neatly autogenerated on GDC...
>> 
>> I'm just tired of making these dual-platform -> cross-platform And just like "printf", this is breeding some bad D practices ?
>> 
>> Pretty please, add "std.c.unix.unix" and version(Unix) to DMD.
>> --anders
>> 
> 
> Seconded.

Thirded.

>> --
>> Elwood: Ah... what kind of music do you usually have here? Claire: Oh we got both kinds. We got Country, and Western.
> 
> Heh, heh - great flick. Just saw it again the other day...

Which reminds me I must buy the new DVD release, I think I've only seen it 9 (or maybe 10-11-12...) times yet.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Anders F Björklund wrote:
> So, just fixed another "bug" that was using version(linux).
> i.e. it worked just fine on Darwin too, if it had compiled.
> What will it take for DMD to support the portable modules ?
> 
> The current situation is not very good. GDC 0.17 is missing
> the std.c.linux.linux due to a slight oversight, but why is
> DMD missing the std.c.unix.unix module ? Or version(Unix) ?
> 
> It's been requested (and needed) for several years now :-(

On Linux I set an environment variable like so:

    DFLAGS=-version=Posix

Not quite as good as compiler support perhaps, but it does the trick.


Sean

Sean Kelly wrote:

> On Linux I set an environment variable like so:
> 
>     DFLAGS=-version=Posix
> 
> Not quite as good as compiler support perhaps, but it does the trick.

It does ?

I could add DFLAGS="-version=Unix" to my DMD invocation guidelines,
and make sure that I copy a version of std/c/unix/unix.d to every
new Phobos, but I will still have to edit all the source code that
uses "version(linux)" and "import std.c.linux.linux;" without need.

If I really wanted to, I could even use both in parallell, like the
workarounds we have used in the past to support both of GDC and DMD:

version(DigitalMars)
    version(linux)
        version = Unix;

version(DigitalMars)
    version(linux)
        import std.c.linux.linux;
version(GNU)
    version(Unix)
        import std.c.unix.unix;

But somehow it's both a ugly workaround, and not worth the effort...
It would be easier if one could use the same source code, for both ?

--anders


PS.
I'm not really sure why Ares changed the name from Unix to Posix,
surely there was a good reason for doing it differently from GDC ?
"Unix", see http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1212
(hope it doesn't mean that we need *three* versions, in the above)

Anders F Björklund wrote:
>
> I'm not really sure why Ares changed the name from Unix to Posix,
> surely there was a good reason for doing it differently from GDC ?
> "Unix", see http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1212
> (hope it doesn't mean that we need *three* versions, in the above)

"POSIX" is an API spec, while "UNIX" is merely a generic term for some systems that implement that spec.  I thought it made more sense to say whether your OS supported the API and leave OS-specific stuff to what's actually OS-specific (in sys/*).  Admittedly, sys/linux/c still contains a bunch of stuff that's actually a part of POSIX, but I'm trying to phase it out as it's implemented in the POSIX headers.


Sean

Sean Kelly wrote:

>> I'm not really sure why Ares changed the name from Unix to Posix,
>> surely there was a good reason for doing it differently from GDC ?
>> "Unix", see http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1212
>> (hope it doesn't mean that we need *three* versions, in the above)
> 
> "POSIX" is an API spec, while "UNIX" is merely a generic term for some systems that implement that spec.  I thought it made more sense to say whether your OS supported the API and leave OS-specific stuff to what's actually OS-specific (in sys/*).

I made the same argument myself, but it seemed like both Walter and David wanted to split it by OS instead, so I just left it at that...

I must have missed this "sys" hierarchy, that is an Ares thing right ?
As I only knew about the Phobos and Deimos roots, and the loose files.

> Admittedly, sys/linux/c still contains a bunch of stuff that's actually a part of POSIX, but I'm trying to phase it out as it's implemented in the POSIX headers.

I recall that GDC had to add the std.c.dirent module, for instance.
Will download Ares, and take a look at this alternative setup...

--anders

Anders F Björklund wrote:
> Sean Kelly wrote:
> 
>>> I'm not really sure why Ares changed the name from Unix to Posix,
>>> surely there was a good reason for doing it differently from GDC ?
>>> "Unix", see http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1212
>>> (hope it doesn't mean that we need *three* versions, in the above)
>>
>> "POSIX" is an API spec, while "UNIX" is merely a generic term for some systems that implement that spec.  I thought it made more sense to say whether your OS supported the API and leave OS-specific stuff to what's actually OS-specific (in sys/*).
> 
> I made the same argument myself, but it seemed like both Walter and David wanted to split it by OS instead, so I just left it at that...
> 
> I must have missed this "sys" hierarchy, that is an Ares thing right ?
> As I only knew about the Phobos and Deimos roots, and the loose files.

Yes it is.  This is the current breakdown:

std.c		- standard C headers
std.c.posix	- POSIX headers
std.c.posix.sys	- same
sys.windows	- Windows-specific D code
sys.windows.c	- Windows C headers

and so on for linux, darwin, etc.

Currently, the files in sys.linux.c duplicate some information in std.c.posix, but I am gradually phasing it out.

>> Admittedly, sys/linux/c still contains a bunch of stuff that's actually a part of POSIX, but I'm trying to phase it out as it's implemented in the POSIX headers.
> 
> I recall that GDC had to add the std.c.dirent module, for instance.
> Will download Ares, and take a look at this alternative setup...

The current Posix headers only support Linux and (to a limited degree) Darwin, but it would be easy enough to add other OSes as well.  I'm taking care of them on an as-needed basis, but there's a decent bit of functionality available so far.


Sean

Sean Kelly wrote:
> Anders F Björklund wrote:
>  >
> 
>> I'm not really sure why Ares changed the name from Unix to Posix,
>> surely there was a good reason for doing it differently from GDC ?
>> "Unix", see http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1212
>> (hope it doesn't mean that we need *three* versions, in the above)
> 
> 
> "POSIX" is an API spec, while "UNIX" is merely a generic term for some systems that implement that spec.  I thought it made more sense to say whether your OS supported the API and leave OS-specific stuff to what's actually OS-specific (in sys/*).  Admittedly, sys/linux/c still contains a bunch of stuff that's actually a part of POSIX, but I'm trying to phase it out as it's implemented in the POSIX headers.
> 
> 
> Sean

POSIX is a very loosely defined spec.  It would be difficult to identify the OSes that claim to be POSIX-compliant that implement radically different behavior.  This is why there are so many POSIX-compliant OSes, NetBSD, FreeBSD, OpenBDS, Linux, Solaris, etc.  Each one of them takes a different stance on how the spec should be implemented, the corner cases, etc.  I'm no expert in such things, but it poses a difficult problem for application developers.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> 
> POSIX is a very loosely defined spec.  It would be difficult to identify the OSes that claim to be POSIX-compliant that implement radically different behavior.  This is why there are so many POSIX-compliant OSes, NetBSD, FreeBSD, OpenBDS, Linux, Solaris, etc.  Each one of them takes a different stance on how the spec should be implemented, the corner cases, etc.  I'm no expert in such things, but it poses a difficult problem for application developers.

Yeah, POSIX stinks like that.  It was an intentional design consideration to avoid restricting POSIX compliance to a limited set of hardware.


Sean