In article <bob35u$2m4j$1@digitaldaemon.com>, Ant says...
>
>In article <boa8ki$1g9u$1@digitaldaemon.com>, Walter says...
>>
>>This includes the new library layout.
>
>yuck, you didn't go far enough,
>... a missed opportunity.

I glad nobody agrees with me! probably means that I'm wrong and we are on the right track after all...

Ant

Perhaps there should be a std.c.unix, containing all the "common" unix functionality, as well as std.c.linux, which has Linux-specific variants.

There is an equivalent for Windows... some API's only existed on older OS, some only exist on newer OS.  .NET is almost an entirely new platform!

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bobguh$ae4$1@digitaldaemon.com...
>
> "Elias Martenson" <elias-m@algonet.se> wrote in message news:boapcb$28cj$1@digitaldaemon.com...
> > I asked this on the wiki but no answer still, so I'm sorry for
> intruding...
>
> You're not intruding. Ask away!
>
> > I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or std.c.posix? There aren't very much linux-specific stuff in there is it?
>
> Good question. The answer is that there are several different families of unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is implemented on them, I can see an std.c.bsdunix, etc., being made for it.
I
> don't see a problem with the likelihood of the bsdunix and linux files
being
> 90% the same.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bocged$1q8f$1@digitaldaemon.com...
> Perhaps there should be a std.c.unix, containing all the "common" unix functionality, as well as std.c.linux, which has Linux-specific variants.

I could see an std.c.posix at some point.

> There is an equivalent for Windows... some API's only existed on older OS, some only exist on newer OS.

Microsoft may deprecate APIs, but they are still supported in all versions of win32. Perhaps you're thinking of win16 (which D doesn't support anyway).

> .NET is almost an entirely new platform!

Yup. There will likely eventually be a std.dotnet.

"J C Calvarese" <jcc7@cox.net> wrote in message news:boca86$1gn4$1@digitaldaemon.com...
> I've been trying to get DIG (Carlos's modified version of 0.0.14) to compile with the new phobos structure in DMD 0.75, so I've gone through and changed all the phobos imports that I could find.
>
> Some of the error message seem to indicate there might be some small problems with phobos.  (But I may just be clueless.)  In any case, these changes seemed to help my situation, so I'm submitting them for your consideration:
>
> phobos\internal\gc\gc.d (change line 16):
> import internal.gc.gcx;
>
> phobos\internal\gc\gcx.d (change line 33):
> import internal.gc.gcbits;
>
> phobos\std\gcx.d (change line 40):
>     import internal.gc.win32;
>
> phobos\internal\gc\gcbits.d (inserted line at top):
> module internal.gc.gcbits;

You should not need to do any of this. The makefile to build internal\gc is \internal\gc\win32.mak, and internal\gc should be the default directory when it is built.

> phobos\std\intrinsic.d (change line 11):
> module std.intrinsic;  /+ was std.math! +/
>
> phobos\std\c\windows\windows.d (inserted line at top):
> module std.c.windows.windows;
>
> phobos\std\ctype.d (inserted line at top):
> module std.ctype;
>
> phobos\std\windows\syserror.d (inserted line at top):
> module std.windows.syserror;
>
>
>
> My latest error message is: net\BurtonRadons\dig\windows\frame.d(9): module gc is in multiple packages std.gc
>
> where the offending line is:
> private import std.gc;
>
> If I change it to:
> private import internal.gc.gc;
>
> My new error message is:
> net\BurtonRadons\dig\windows\base.d(7): import std conflicts with
> windows.std at net\BurtonRadons\dig\windows\windows.d(7)
>
> net\BurtonRadons\dig\windows\windows.d(7):
> import std.c.windows.windows;
>
> net\BurtonRadons\dig\windows\base.d(7):
> import std.ctype;
>
> I'm running around in circles at this point (I don't even know what direction I should be going).  Any ideas, hints, tips, pointers, etc. would be must appreciated.

Generally, the way to isolate these problems is to produce a minimal .d source file that reproduces them.

Walter wrote:

> "Y.Tomino" <demoonlit@inter7.jp> wrote in message
> news:boar82$2auv$1@digitaldaemon.com...
> 
>>It's glad for me that almost "import" were set to "private".
>>Why are these "public" still ?
>>
>>random.d:
>>import std.c.linux.linux;
>>
>>thread.d
>>import std.c.windows.windows;
>>
>>YT
> 
> 
> Sloth on my part. They should be private.
> 
> 

Is is necessary for std.stream to import two modules at the end of the stream.d file?  (I'd think it would be better for the individual programmer to explicitly import them.)

import std.string;
import std.file;

Just checking...

Justin

Walter wrote:

> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:boca86$1gn4$1@digitaldaemon.com...
> 
>>I've been trying to get DIG (Carlos's modified version of 0.0.14) to
>>compile with the new phobos structure in DMD 0.75, so I've gone through
>>and changed all the phobos imports that I could find.
>>
>>Some of the error message seem to indicate there might be some small
>>problems with phobos.  (But I may just be clueless.)  In any case, these
>>changes seemed to help my situation, so I'm submitting them for your
>>consideration:
>>
>>phobos\internal\gc\gc.d (change line 16):
>>import internal.gc.gcx;
>>
>>phobos\internal\gc\gcx.d (change line 33):
>>import internal.gc.gcbits;
>>
>>phobos\std\gcx.d (change line 40):
>>    import internal.gc.win32;
>>
>>phobos\internal\gc\gcbits.d (inserted line at top):
>>module internal.gc.gcbits;
> 
> 
> You should not need to do any of this. The makefile to build internal\gc is
> \internal\gc\win32.mak, and internal\gc should be the default directory when
> it is built.

Okay, nevermind.

> 
> 
>>phobos\std\intrinsic.d (change line 11):
>>module std.intrinsic;  /+ was std.math! +/

^ I still think I found something here.

It probably doesn't matter, but math.d is already called std.math, so I think intrinsic.d should be called std.intrinsic.

>>
>>phobos\std\c\windows\windows.d (inserted line at top):
>>module std.c.windows.windows;
>>
>>phobos\std\ctype.d (inserted line at top):
>>module std.ctype;
>>
>>phobos\std\windows\syserror.d (inserted line at top):
>>module std.windows.syserror;
>>
>>
>>
>>My latest error message is:
>>net\BurtonRadons\dig\windows\frame.d(9): module gc is in multiple
>>packages std.gc
>>
>>where the offending line is:
>>private import std.gc;
>>
>>If I change it to:
>>private import internal.gc.gc;
>>
>>My new error message is:
>>net\BurtonRadons\dig\windows\base.d(7): import std conflicts with
>>windows.std at net\BurtonRadons\dig\windows\windows.d(7)
>>
>>net\BurtonRadons\dig\windows\windows.d(7):
>>import std.c.windows.windows;
>>
>>net\BurtonRadons\dig\windows\base.d(7):
>>import std.ctype;
>>
>>I'm running around in circles at this point (I don't even know what
>>direction I should be going).  Any ideas, hints, tips, pointers, etc.
>>would be must appreciated.
> 
> 
> Generally, the way to isolate these problems is to produce a minimal .d
> source file that reproduces them.
> 
Thanks, that's a good approach.  I posted because so many files are involved and the error message is so mysterious to me.  I thought that someone might have an idea what the root cause was.  (I've probably bit off more than I can chew here.)

If I can cut it down to a simple example, I'll post it, but this seems to be one of those problems that disappears when the complicated stuff is taken out.

Justin

"J C Calvarese" <jcc7@cox.net> wrote in message news:boci9u$1st3$1@digitaldaemon.com...
> Is is necessary for std.stream to import two modules at the end of the stream.d file?  (I'd think it would be better for the individual programmer to explicitly import them.)
>
> import std.string;
> import std.file;
>
> Just checking...

I don't know. I didn't write stream.d.

Walter wrote:

> "Elias Martenson" <elias-m@algonet.se> wrote in message
> news:boapcb$28cj$1@digitaldaemon.com...
> 
>>I asked this on the wiki but no answer still, so I'm sorry for
> 
> intruding...
> 
> You're not intruding. Ask away!

Thanks. :-)  It feels a bit scary commenting on the language design of a language I just started to learn. :-)

>>I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or
>>std.c.posix? There aren't very much linux-specific stuff in there is it?
> 
> Good question. The answer is that there are several different families of
> unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is
> implemented on them, I can see an std.c.bsdunix, etc., being made for it. I
> don't see a problem with the likelihood of the bsdunix and linux files being
> 90% the same.

I'd like to argue that it's more like 99% the same. In fact, I have a hard time remembering if I ever write a C program that used Linux-specific functionality.

Having whatever Linux specific stuff in std.c.linux is good in my mind, but it would feel a lot better to use std.c.posix for the 99% which isn't.

Other than that, thanks a lot of your work, it's appreciated! (even though I do some C++ programming at work, I can't say I like it. I'd love to see D replace both C and C++ as a popular systems language).

"Elias Martenson" <elias-m@algonet.se> wrote in message news:bod2c5$2m03$1@digitaldaemon.com...
> >>I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or std.c.posix? There aren't very much linux-specific stuff in there is it?
> > Good question. The answer is that there are several different families
of
> > unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is implemented on them, I can see an std.c.bsdunix, etc., being made for
it. I
> > don't see a problem with the likelihood of the bsdunix and linux files
being
> > 90% the same.
> I'd like to argue that it's more like 99% the same. In fact, I have a hard time remembering if I ever write a C program that used Linux-specific functionality.

It probably is 99% the same. One of the other problems I didn't mention, though, is the problem of updating it. Suppose D supports a dozen unix variants with the same module. I don't have access to all these variants. I update the module for abcunix, and inadvertently break xyzunix which does it differently.

I'd rather have abcunix and xyzunix as separate modules, so that presumably whoever is updating xyzunix is doing it on an xyzunix box and won't be breaking any of the other unix support. Then, maintainers of each of the unix variants can fold/test the changes in when convenient.

> Having whatever Linux specific stuff in std.c.linux is good in my mind, but it would feel a lot better to use std.c.posix for the 99% which isn't.
>
> Other than that, thanks a lot of your work, it's appreciated! (even though I do some C++ programming at work, I can't say I like it. I'd love to see D replace both C and C++ as a popular systems language).

Thanks! I would, too!

"Mark T" <Mark_member@pathlink.com> wrote in message news:bobgd9$9ic$1@digitaldaemon.com...

> Probably should have been std.c.unix for UNIX/POSIX stuff and
std.c.unix.linux
> for Linux only specific stuff (if any).  I don't think Walter uses any
other
> UNIX besides Linux so he may not feel comfortable in this area.

There's a problem right there. The current implementation doesn't allow a .d module and a folder with the same name. It's imposible to have std/c/unix.d and std/c/unix/linux.d becouse the compiler will complain with:

C:\dmd\test.d(2): import unix package and module have the same name