www.digitalmars.com         C & C++   DMDScript  

D - Library naming convention

reply "Walter" <walter digitalmars.com> writes:
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.

So here goes:

std
 Contains the 'standard' modules that will be available on all
 implementations of D. Emphasis in this package will be on reliability,
 stability, and portability. std as a name has the advantage of being used
 in C++ to specify the standard library, and so is familiar and highly
 unlikely to conflict with common variable names.

std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.

std.os
 Access to platform specific functionality.

std.os.windows
 Specific to win32 and win64 operating systems. (win64
 is coming, so calling it 'win32' would be a mistake.)
 The excellent point was raised about operating system
 specific code not being in the std tree as it evolves
 constantly. I understand that point, but operating systems
 evolve by adding API's, not subtracting them. So any
 windows package should continue to work as long as there's
 a windows operating system.

std.os.linux
 Specific to linux operating systems.

std.typeinfo
 Where the various TypeInfo implementations go.

internal
 Internal magic implementation-specific runtime support code.

etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

These names have the advantage of being reasonably greppable.

Major packages, such as a D gui, will merit their own toplevel name. Vendor
specific modules will use a toplevel name being the trademarked vendor name.
For example, vendor BrandX would put their vendor specific packages under
the toplevel name brandx.

Much as I'd prefer to use D or d as the toplevel name, it just isn't going
to work because of conflicts, non-greppability, etc.
Oct 28 2003
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. 

 So it's up to me to just pick
 one of the right answers.
 
 So here goes:
 
 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.

So in the future, we'll be talking about std.string, std.regexp, std.thread, std.uri, std.utf and others? (I'm trying to make sure that I understand.)
 
 std.c
  Contains D interfaces to standard C library functions, like
  std.c.stdio, std.c.stdlib, std.c.math.
 
 std.os
  Access to platform specific functionality.
 
 std.os.windows
  Specific to win32 and win64 operating systems. (win64
  is coming, so calling it 'win32' would be a mistake.)
  The excellent point was raised about operating system
  specific code not being in the std tree as it evolves
  constantly. I understand that point, but operating systems
  evolve by adding API's, not subtracting them. So any
  windows package should continue to work as long as there's
  a windows operating system.
 
 std.os.linux
  Specific to linux operating systems.
 
 std.typeinfo
  Where the various TypeInfo implementations go.
 
 internal
  Internal magic implementation-specific runtime support code.

 
 etc
  There are lots of 'other' modules for D, and right now there is no
  organized way to deal with them. There needs to be a place for them.
  The etc heirarchy will mirror the standard one, i.e. there will
  be etc.c, etc.os.windows, ... These will not be official parts of D
  nor will they be standardized. However, candidates for standardization
  will be drawn from etc. etc is the place for
  not-quite-there-yet-but-still-useful modules.
 
 These names have the advantage of being reasonably greppable.
 
 Major packages, such as a D gui, will merit their own toplevel name. Vendor
 specific modules will use a toplevel name being the trademarked vendor name.
 For example, vendor BrandX would put their vendor specific packages under
 the toplevel name brandx.
 

Sounds like a good plan. (I'm glad that I don't have to put my packages in "other.com.tripod.jcc_7".)
 Much as I'd prefer to use D or d as the toplevel name, it just isn't going
 to work because of conflicts, non-greppability, etc.

Justin http://jcc_7.tripod.com/d/
Oct 28 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being


  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.

So in the future, we'll be talking about std.string, std.regexp, std.thread, std.uri, std.utf and others? (I'm trying to make sure that I understand.)

I hope not. Shouldn't string, regexp and the like go "under" something else, and shouldn't "thread" go under std.lang?
Oct 28 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnng71$20up$2 digitaldaemon.com...
 I hope not. Shouldn't string, regexp and the like go "under" something

 and shouldn't "thread" go under std.lang?

Why?
Oct 28 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Isn't it a language feature, rather than a library feature?

Maybe thread wasn't the best example. The class info stuff?

"Walter" <walter digitalmars.com> wrote in message
news:bnnjkd$2683$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnng71$20up$2 digitaldaemon.com...
 I hope not. Shouldn't string, regexp and the like go "under" something

 and shouldn't "thread" go under std.lang?

Why?

Oct 28 2003
parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnnlgq$28ib$1 digitaldaemon.com...
 Isn't it a language feature, rather than a library feature?

 Maybe thread wasn't the best example. The class info stuff?

The line between can get pretty fuzzy at times. The os packages clearly mark using them as non-portable, but I don't see the equivalent value added for dividing between language and library.
Oct 29 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:bnnb81$1qem$1 digitaldaemon.com...
 So in the future, we'll be talking about std.string, std.regexp,
 std.thread, std.uri, std.utf and others?  (I'm trying to make sure that
 I understand.)

Yes. I also tend to prefer flatter, more populated heirarchies, rather than deep, thinly populated heirarchies like: std.this.that.foo.bar.common.implementation.abc.thread.
Oct 28 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Is this the official final word?

Is this the official final structure?

I'm pretty happy with it as is, although I'd like to see a std.lang where
language bits reside.

Oh, and a std.c.recls. :)

"Walter" <walter digitalmars.com> wrote in message
news:bnn9a0$1o09$1 digitaldaemon.com...
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. So it's up to me to just pick
 one of the right answers.

 So here goes:

 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.

 std.c
  Contains D interfaces to standard C library functions, like
  std.c.stdio, std.c.stdlib, std.c.math.

 std.os
  Access to platform specific functionality.

 std.os.windows
  Specific to win32 and win64 operating systems. (win64
  is coming, so calling it 'win32' would be a mistake.)
  The excellent point was raised about operating system
  specific code not being in the std tree as it evolves
  constantly. I understand that point, but operating systems
  evolve by adding API's, not subtracting them. So any
  windows package should continue to work as long as there's
  a windows operating system.

 std.os.linux
  Specific to linux operating systems.

 std.typeinfo
  Where the various TypeInfo implementations go.

 internal
  Internal magic implementation-specific runtime support code.

 etc
  There are lots of 'other' modules for D, and right now there is no
  organized way to deal with them. There needs to be a place for them.
  The etc heirarchy will mirror the standard one, i.e. there will
  be etc.c, etc.os.windows, ... These will not be official parts of D
  nor will they be standardized. However, candidates for standardization
  will be drawn from etc. etc is the place for
  not-quite-there-yet-but-still-useful modules.

 These names have the advantage of being reasonably greppable.

 Major packages, such as a D gui, will merit their own toplevel name.

 specific modules will use a toplevel name being the trademarked vendor

 For example, vendor BrandX would put their vendor specific packages under
 the toplevel name brandx.

 Much as I'd prefer to use D or d as the toplevel name, it just isn't going
 to work because of conflicts, non-greppability, etc.

Oct 28 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bnng70$20up$1 digitaldaemon.com>, Matthew Wilson says...

Allow me to suggest stdd "std" on google gets 6.470.00 "stdd" gets 4.700 Ant
Oct 28 2003
parent "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bnnglq$21fi$1 digitaldaemon.com...
 In article <bnng70$20up$1 digitaldaemon.com>, Matthew Wilson says...

Allow me to suggest stdd "std" on google gets 6.470.00 "stdd" gets 4.700

D gets 315,000,000 <g>. Interestingly, std.thread gets 369, std.string gets 102,000, std.regexp gets 8.
Oct 28 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnng70$20up$1 digitaldaemon.com...
 Is this the official final word?
 Is this the official final structure?

Unless someone points out a disastrous problem with it <g>.
 I'm pretty happy with it as is, although I'd like to see a std.lang where
 language bits reside.

I'm just going for a workable system, having long since given up on perfection. Let's just cut & print and move on to more interesting things!
 Oh, and a std.c.recls. :)

Oct 28 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I'm just going for a workable system, having long since given up on
 perfection. Let's just cut & print and move on to more interesting things!

You mean like std.c.recls? :)
Oct 28 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 There have been a lot of good ideas and points made about this in the
 discussions here. The upshot is there isn't a single right answer,
 but there are a few clearly wrong ones <g>. So it's up to me to just pick
 one of the right answers.
 
 So here goes:
 
 std
  Contains the 'standard' modules that will be available on all
  implementations of D. Emphasis in this package will be on reliability,
  stability, and portability. std as a name has the advantage of being used
  in C++ to specify the standard library, and so is familiar and highly
  unlikely to conflict with common variable names.

That's a good decision. By what formal or informal procedure can one contribute modules? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Oct 28 2003
parent "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F9F6104.A4076357 chello.at...
 That's a good decision.

Thank-you.
 By what formal or informal procedure can one contribute modules?

Certainly, it's informal. Which means any way you want to <g>.
Oct 29 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 std
 ...

Just to keep track: <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout> -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Oct 28 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F9F6290.6FB11680 chello.at...
 Walter wrote:
 std
 ...

Just to keep track: <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>

Nice. Thanks for keeping that up to date!
Oct 29 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 Just to keep track:
    <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>


May suggest: Original: -------------------- std.os Access to platform specific functionality. std.os.windows Specific to win32 and win64 operating systems. (win64 is coming, so calling it ... std.os.linux Specific to linux operating systems. (StdOsLinuxComments) -------------------- Modified: -------------------- std.os Access to OS-level, platform-independent functionality. std.os.windows ... ... -------------------- Or do I misunderstand something? (Sorry I just dind't dare Editing directly in the Wiki. I'm a shy one... :) ) Cheers, Sz.
Oct 29 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 May suggest:

 Original:
 --------------------
 std.os
     Access to platform specific functionality.

 std.os.windows
     Specific to win32 and win64 operating systems. (win64 is coming, so

     ...

 std.os.linux
     Specific to linux operating systems. (StdOsLinuxComments)
 --------------------

 Modified:
 --------------------
 std.os
     Access to OS-level, platform-independent functionality.

 std.os.windows
     ...
 ...
 --------------------

Good point.
 Or do I misunderstand something?

 (Sorry I just dind't dare Editing directly in the Wiki.
 I'm a shy one... :) )

LOL
Oct 29 2003
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Luna Kid wrote:

Just to keep track:
   <http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout>


May suggest: Original: -------------------- std.os Access to platform specific functionality. ... Modified: -------------------- std.os Access to OS-level, platform-independent functionality. ... Or do I misunderstand something?

The way I read it, "std.os" would only contain code that relates to platform-dependent (a/k/a platform-specific) functionality. It would probably contain only a series of directories: "windows", "linux", and any other platforms with D implementations. The platform-independent code would reside elsewhere in "std", "internal", or "etc".
 
 (Sorry I just dind't dare Editing directly in the Wiki.
 I'm a shy one... :) )

Don't be afaid to edit the Wiki stuff. That's what Wiki's are designed for. They're easy to edit and they're easy to change back. Justin
 
 Cheers,
 Sz.
 
 

Oct 29 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
 --------------------
 std.os
     Access to platform specific functionality.
     ...


 Modified:
 --------------------
 std.os
     Access to OS-level, platform-independent functionality.
     ...

 Or do I misunderstand something?

The way I read it, "std.os" would only contain code that relates to platform-dependent (a/k/a platform-specific) functionality. It would probably contain only a series of directories: "windows", "linux", and any other platforms with D implementations.

Well, dunno, but even without knowing how this really is in D, I'm still almost sure a namespace node is not restricted to contain either leaf nodes or another subnamespaces. Cheers, Sz.
Oct 30 2003
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
[...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

What does 'etc' stand for? I'd prefer 'ext', that means extension. Ciao
Oct 30 2003
next sibling parent "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
I agree. At least I don't like etc.

Lars Ivar Igesund

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bnqp2a$i4q$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
 [...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

What does 'etc' stand for? I'd prefer 'ext', that means extension. Ciao

Oct 30 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Roberto Mariottini wrote:
 
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
 [...]
etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

What does 'etc' stand for? I'd prefer 'ext', that means extension.

I don't think we need to take this so literally. Walter surely will find better places in std for most modules. I think its just an "default" case: "...and if we really don't know where to put a module, then we have still this place..." If no-one likes it, just the better. Nothing should ever go there. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Oct 30 2003
next sibling parent reply user domain.invalid writes:
Helmut Leitner wrote:

 I don't think we need to take this so literally.
 
 Walter surely will find better places in std for most modules. 
 I think its just an "default" case: "...and if we really don't
 know where to put a module, then we have still this place..."
 
 If no-one likes it, just the better. Nothing should ever go there.

The less the better. Remember what happened to Java in this respect? javax.sql.* was intruduced containing JDBC 3.0 stuff. Now that it's part of JDK 1.4 it's still in javax since moving it would cause no end of compatibility problems. Once in etc, it will stay in etc, so it's better to never put it there in the first place. Just my personal opinion. Regards Elias
Oct 30 2003
parent reply Andy Friesen <andy ikagames.com> writes:
user domain.invalid wrote:

 Once in etc, it will stay in etc, so it's better to never put it there 
 in the first place.
 
 Just my personal opinion.
 
 Regards
 
 Elias

hm. That brings up an idea. The etc.blah module could later be rewritten as: deprecated import proper.place.to.put.blah; Supposing that imports can be marked as deprecated. So the etc package would probably get pretty bloaty over time, but the compiler would bitch at everybody who tries to use it, and it would all just be redirecting, so size and so forth would not suffer. (better to put it in the right place right off the bat, sure, but that's not as easy as it sounds sometimes) -- andy
Oct 30 2003
parent Elias Martenson <elias-m algonet.se> writes:
Andy Friesen wrote:

 user domain.invalid wrote:
 
 Once in etc, it will stay in etc, so it's better to never put it there 
 in the first place.

 Just my personal opinion.

 Regards

 Elias

hm. That brings up an idea. The etc.blah module could later be rewritten as: deprecated import proper.place.to.put.blah; Supposing that imports can be marked as deprecated. So the etc package would probably get pretty bloaty over time, but the compiler would bitch at everybody who tries to use it, and it would all just be redirecting, so size and so forth would not suffer. (better to put it in the right place right off the bat, sure, but that's not as easy as it sounds sometimes)

First of all: sorry for not having configured my email address properly, it shuld be fixed now. The redirect idea sounds nice, and IMHO it's the only thing that works. Java has provided us with a very good warning. The redirect idea is a good workaround but you have to agree, it's a hack. :-) Elias
Oct 30 2003
prev sibling parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Helmut Leitner wrote:

Roberto Mariottini wrote:
  

In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
[...]
    

etc
There are lots of 'other' modules for D, and right now there is no
organized way to deal with them. There needs to be a place for them.
The etc heirarchy will mirror the standard one, i.e. there will
be etc.c, etc.os.windows, ... These will not be official parts of D
nor will they be standardized. However, candidates for standardization
will be drawn from etc. etc is the place for
not-quite-there-yet-but-still-useful modules.
      

I'd prefer 'ext', that means extension.

I don't think we need to take this so literally. Walter surely will find better places in std for most modules. I think its just an "default" case: "...and if we really don't know where to put a module, then we have still this place..." If no-one likes it, just the better. Nothing should ever go there.

I think etc would be a good place to get early access to new ideas and modules, like in openGL's extension mechanism. There may be allot of (constructive) argument about one aspect of something, and it could be threshed out in more then one prototype implementation, parhaps by several different companies for example. When one implementation becomes widely accepted, it would be moved over the the main lot as a new library. It's a good for people who just want to get on with the coding. But I think ext is a better name for that.
Oct 30 2003
parent "Walter" <walter digitalmars.com> writes:
"J Anderson" <anderson badmama.com.au.REMOVE> wrote in message
news:bnr4eh$10q3$1 digitaldaemon.com...
 I think etc would be a good place to get early access to new ideas and
 modules, like in openGL's extension mechanism.  There may be allot of
 (constructive) argument about one aspect of something, and it could be
 threshed out in more then one prototype implementation, parhaps by
 several different companies for example.  When one implementation
 becomes widely accepted, it would be moved over the the main lot as a
 new library.  It's a good for people who just want to get on with the
 coding.

Yes, exactly.
Oct 30 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bnqp2a$i4q$1 digitaldaemon.com...
 What does 'etc' stand for?

'etcetera, etcetera, etcetera' (doing my best Yul Brynner impersonation)
Oct 30 2003
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Roberto Mariottini wrote:
 ...
 What does 'etc' stand for?
 I'd prefer 'ext', that means extension.
 
 Ciao
 
 

etc stands for "et cetera", approx the same as "and other stuff" (with the normal implication "and other similar stuff"). Orig. from the latin, but now common in English, and rather like the German z.b. (which I can't quite remember the expansion of). In the context of computers, /etc is the root level directory where Linux/Unix programs get their configuration files, and where System V descendand versions of Unix (also Linux) systems get their boot time information about what services should be started, etc. I'm not sure whether Walter was saying that there would literally be a library directory named etc, or whether he was saying the other similar directory names would exist. (Both are plausible.)
Oct 31 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Charles Hixson wrote:
 etc stands for "et cetera", approx the same as "and other stuff" (with 
 the normal implication "and other similar stuff").  Orig. from the 
 latin, but now common in English, and rather like the German z.b. (which 
 I can't quite remember the expansion of).

If you're going to be a smart ass, please make sure that what you say is correct ;) The german equivalent of "etc." would be "usw." = "und so weiter", which roughly means "and so on". z.B. is the short form of "zum Beispiel" which means "for example". And yes, I'm a smart ass too ;). Hauke
Oct 31 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnunf3$e0l$1 digitaldaemon.com...
 And yes, I'm a smart ass too ;).

Aren't we all? <g>
Oct 31 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnunf3$e0l$1 digitaldaemon.com...
 z.B. is the short form of "zum Beispiel" which means "for example".

In English we use the Latin "e.g." I always get e.g. and i.e. mixed up. "i.e." means "that is". I'm not sure why we use those abbreviations if we don't know what they mean. I think we know what they mean but we don't know why they mean what they mean, if you know what I mean.
 And yes, I'm a smart ass too ;).

Your point is...? ;)
Nov 01 2003
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Hauke Duden wrote:
 Charles Hixson wrote:
 ...
 latin, but now common in English, and rather like the German z.b. 
 (which I can't quite remember the expansion of).

z.B. is the short form of "zum Beispiel" which means "for example". And yes, I'm a smart ass too ;). Hauke

Sorry, it's been a number of decades. My appologies.
Nov 01 2003
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...


std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.

kinda like puting together stawberies and chilly peppers because they are the same color... (I know Walter will never change his mind (reverse psychology) but the rest of you has to agree ;) Ant
Oct 30 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Yes, I do.

I don't like that part. I think modules should be broken down logically,
rather on implementation details.

I don't care if something is implemented in C or in D, rather what it can do
for me.

There's a deeper aspect to this. I'm biased on this issue, so you'll have to
take the following with a pinch of salt.

For those of you who do not know, I'm creating a platform-independent,
source-supplied, recursive searching library called recls
(http://recls.org/), and documented in my bi-monthly in-print CUJ column. It
is implemented in C/C++, presents a C interface to the world, and it is to
be mapped to just about any language you can think of (C++, D, Java, .NET,
Perl, Python, Ruby, etc.). There's a beta D mapping available at the
website.

I can't see any reason why recls, and similar libraries, can't become part
of the standard distribution of D, since there're no royalty implications.
However, since it is written in C/C++, it is not 100% pure D. This is
absolutely no impediment to using D on Win32 or UNIX, and I would bet that
recls will be ported to MAC and other platforms before D is. (Even if it's
not, it would be a simple matter to do so.)

People who've used the library so far have said it's very useful (some have
commented that it's the rec-search they always wanted, which is nice), but I
think it will be rejected by the DLG (if we ever get one) because it's not
D.

Anyway, feel free to dismiss this as a self-promotion rant, but I think it's
a good example of an issue we're going to come up against a great deal. Why
reject, or cause to be rewritten, or squirrel away in the "dirty C corner"
libraries that already exist (and is tested), since D makes a big point of C
compatibility in the first place?


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

----------------------------------------------------------------------------
---



"Ant" <Ant_member pathlink.com> wrote in message
news:bns6d8$2gv2$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...


std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.

kinda like puting together stawberies and chilly peppers because they are the same color... (I know Walter will never change his mind (reverse psychology) but the rest of you has to agree ;) Ant

Oct 30 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bns6u8$2hnq$1 digitaldaemon.com...
 I don't care if something is implemented in C or in D, rather what it can

 for me.

You're right, it doesn't matter if the library is implemented in C or D. But it *does* matter if it follows C or D conventions. For example, if a module uses errno or error numbers, 0 terminated strings, expects the caller to use malloc/free on data passed through its interface, etc., I'd prefer to put it under a C package so that gives the potential user of it some extra notification that it does not follow D conventions. D conventions would be using exceptions for error notification, length'd (!) strings, garbage collection, COW, etc. A typical C package can be 'wrapped' to give it D conventions, and then it would be suitable for inclusion in a non-C heirarchy. I am currently working on a D version of the popular zlib module for just that reason. The underlying implementation will remain in C (it's a pointless waste of time to convert that code to D).
 Anyway, feel free to dismiss this as a self-promotion rant, but I think

 a good example of an issue we're going to come up against a great deal.

 reject, or cause to be rewritten, or squirrel away in the "dirty C corner"
 libraries that already exist (and is tested), since D makes a big point of

 compatibility in the first place?

I'd call it the "C corner", not the "dirty C corner" <G>. All that would mean to the D user of the package would be he'd need to double check things like 0 terminated strings, returned error codes, storage allocation, and other C conventions.
Oct 30 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I don't care if something is implemented in C or in D, rather what it


 do
 for me.

You're right, it doesn't matter if the library is implemented in C or D.

 it *does* matter if it follows C or D conventions. For example, if a

 uses errno or error numbers, 0 terminated strings, expects the caller to

 malloc/free on data passed through its interface, etc., I'd prefer to put

 under a C package so that gives the potential user of it some extra
 notification that it does not follow D conventions.

 D conventions would be using exceptions for error notification, length'd

 strings, garbage collection, COW, etc.

 A typical C package can be 'wrapped' to give it D conventions, and then it
 would be suitable for inclusion in a non-C heirarchy. I am currently

 on a D version of the popular zlib module for just that reason. The
 underlying implementation will remain in C (it's a pointless waste of time
 to convert that code to D).

 Anyway, feel free to dismiss this as a self-promotion rant, but I think

 a good example of an issue we're going to come up against a great deal.

 reject, or cause to be rewritten, or squirrel away in the "dirty C


 libraries that already exist (and is tested), since D makes a big point


 C
 compatibility in the first place?

I'd call it the "C corner", not the "dirty C corner" <G>. All that would mean to the D user of the package would be he'd need to double check

 like 0 terminated strings, returned error codes, storage allocation, and
 other C conventions.

Ok, I see that. But in that case, you'll have the hierarchies on their heads std.c.filesystem.recls - the C stuff std.filesystem.recls - the D stuff whereas what we should see is std.filesystem.recls.c - the C stuff std.filesystem.recls - the D stuff (I realise that recls.c.d is not going to work, under the current naming system) How've you done the zlib module naming? I assume the C interface and a D layer are both provided?
Oct 30 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their

 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current naming
 system)

 How've you done the zlib module naming? I assume the C interface and a D
 layer are both provided?

Here's what I did. First, I did a simple module with declarations to make the C zlib functions accessible from D. It makes no attempt to hide zlib's C conventions. This will not be an official D package, but is still useful, so I stuffed it in etc.c.zlib. Then I build a D version that implements a conventional D interface to the zlib functionality. I called this std.zlib. Now, it works out that std.zlib is implemented by calling the functions in etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of std.zlib. In the future, I can see porting the zlib C code to D and implementing them directly in std.zlib. But that won't affect the user of std.zlib, except that it might be a little smaller and faster.
Oct 30 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
I totally agree that users of std.zlib should not have to care about
etc.c.zlib

However, where we seem to disagree (and not just here) is that the D way,
which is (reading between the lines) an OO + exceptions way, is the only
way. This is what I rail against.

I want etc.c.filesystem.recls to be accessible to programmers and just as
valid and supported as std.filesystem.recls, or whatever, and the sames
probably goes for etc.c.zlib (unless you've made it pretty ugly and
unusable).

If we have to program in only one way in D, then people will be (rightly)
turned off. If not, then the thin C=>D translator layers should be
accessible, and not in a curious corner, but in a logical place.

The world is a rich place, and the "one way or the highway" is that popular
and efficient language Java. It's horses for courses, and D should support
all models, and prescribe as little as possible.

Don't you agree?


"Walter" <walter digitalmars.com> wrote in message
news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their

 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current naming
 system)

 How've you done the zlib module naming? I assume the C interface and a D
 layer are both provided?

Here's what I did. First, I did a simple module with declarations to make the C zlib functions accessible from D. It makes no attempt to hide zlib's

 conventions. This will not be an official D package, but is still useful,

 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this

 Now, it works out that std.zlib is implemented by calling the functions in
 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing

 directly in std.zlib. But that won't affect the user of std.zlib, except
 that it might be a little smaller and faster.

Oct 30 2003
parent reply "Walter" <walter digitalmars.com> writes:
I guess where I disagree with you is that putting something that uses C
conventions under a package named 'std.c' is some undesirable place. I don't
think it's some unfavored place at all, it just acknowledges that it uses
different conventions. I also feel that there should be some style
consistency in standard D library code. Having one module use errno and
another use exceptions just makes it look like a hodgepodge. If one package
does something unconventional, it needs to have a strong reason for the
divergence.

The D way is using exceptions for error notification rather than error
codes, but is not necessarilly OO. Several D modules, such as std.string and
std.math, are not OO at all.

BTW, the etc.c.zlib is just as usable or unusable as the C zlib library is,
as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib to
figure out what they're good for and how to use them, that's unacceptable),
it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an easy
face on it made sense, and the result is std.zlib.

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnsse5$j54$1 digitaldaemon.com...
 I totally agree that users of std.zlib should not have to care about
 etc.c.zlib

 However, where we seem to disagree (and not just here) is that the D way,
 which is (reading between the lines) an OO + exceptions way, is the only
 way. This is what I rail against.

 I want etc.c.filesystem.recls to be accessible to programmers and just as
 valid and supported as std.filesystem.recls, or whatever, and the sames
 probably goes for etc.c.zlib (unless you've made it pretty ugly and
 unusable).

 If we have to program in only one way in D, then people will be (rightly)
 turned off. If not, then the thin C=>D translator layers should be
 accessible, and not in a curious corner, but in a logical place.

 The world is a rich place, and the "one way or the highway" is that

 and efficient language Java. It's horses for courses, and D should support
 all models, and prescribe as little as possible.

 Don't you agree?


 "Walter" <walter digitalmars.com> wrote in message
 news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on their

 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current



 system)

 How've you done the zlib module naming? I assume the C interface and a



 layer are both provided?

Here's what I did. First, I did a simple module with declarations to


 the C zlib functions accessible from D. It makes no attempt to hide


 C
 conventions. This will not be an official D package, but is still


 so
 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this

 Now, it works out that std.zlib is implemented by calling the functions


 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user


 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing

 directly in std.zlib. But that won't affect the user of std.zlib, except
 that it might be a little smaller and faster.


Oct 31 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I guess where I disagree with you is that putting something that uses C
 conventions under a package named 'std.c' is some undesirable place. I

 think it's some unfavored place at all, it just acknowledges that it uses
 different conventions. I also feel that there should be some style
 consistency in standard D library code. Having one module use errno and
 another use exceptions just makes it look like a hodgepodge. If one

 does something unconventional, it needs to have a strong reason for the
 divergence.

One man's hodgepodge is another man's freedom of expression.
 The D way is using exceptions for error notification rather than error
 codes, but is not necessarilly OO. Several D modules, such as std.string

 std.math, are not OO at all.

I really don't think obliging people to always favour exceptions is going to fly. Exception-handling is the emporer's new clothes; nobody dares to speak their qualms. That's not to say I don't use it, or believe it is useful, but I've got both feet firmly in the Kernighan and Pike camp. Exceptions are for exceptional circumstances. I don't think all that is error-handling falls within that description. But, sure, other people have different opinions, and paradigms of work. But that backs up my argument that we should support multiple programming paradigms. As to the consistency issue, I think that modules that are exclusively free functions should not use exceptions for error-handling. Those that are class-based are another matter.
 BTW, the etc.c.zlib is just as usable or unusable as the C zlib library

 as that's all it is. I find it more complex than necessary (there are a
 number of parameters you basically have to read the source code to zlib to
 figure out what they're good for and how to use them, that's

 it has a bunch of stuff related to storage allocation, and it uses error
 codes rather than exceptions. Hence, I decided a D wrapper that put an

 face on it made sense, and the result is std.zlib.

I've got no problem with this. I couldn't agree more. C libs should have user friendly layers put over them. But they should also be available for use, since virtually any layer adds stuff that may not be necessary under all circumstances. I see three levels of APIs. 1. Raw C APIs 2. D-ified C APIs, and D free functions 3. Classes I am not arguing for much, if any, of 1, but I am arguing strongly that 2 is just as valid as 3.
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsse5$j54$1 digitaldaemon.com...
 I totally agree that users of std.zlib should not have to care about
 etc.c.zlib

 However, where we seem to disagree (and not just here) is that the D


 which is (reading between the lines) an OO + exceptions way, is the only
 way. This is what I rail against.

 I want etc.c.filesystem.recls to be accessible to programmers and just


 valid and supported as std.filesystem.recls, or whatever, and the sames
 probably goes for etc.c.zlib (unless you've made it pretty ugly and
 unusable).

 If we have to program in only one way in D, then people will be


 turned off. If not, then the thin C=>D translator layers should be
 accessible, and not in a curious corner, but in a logical place.

 The world is a rich place, and the "one way or the highway" is that

 and efficient language Java. It's horses for courses, and D should


 all models, and prescribe as little as possible.

 Don't you agree?


 "Walter" <walter digitalmars.com> wrote in message
 news:bnsrb4$h4o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnsfit$2tsp$1 digitaldaemon.com...
 Ok, I see that. But in that case, you'll have the hierarchies on




 heads
 std.c.filesystem.recls - the C stuff
 std.filesystem.recls - the D stuff

 whereas what we should see is

 std.filesystem.recls.c - the C stuff
 std.filesystem.recls - the D stuff

 (I realise that recls.c.d is not going to work, under the current



 system)

 How've you done the zlib module naming? I assume the C interface and




 D
 layer are both provided?

Here's what I did. First, I did a simple module with declarations to


 the C zlib functions accessible from D. It makes no attempt to hide


 C
 conventions. This will not be an official D package, but is still


 so
 I stuffed it in etc.c.zlib. Then I build a D version that implements a
 conventional D interface to the zlib functionality. I called this

 Now, it works out that std.zlib is implemented by calling the



 in
 etc.c.zlib, but that is quite irrelevant to (and hidden from) the user


 std.zlib.

 In the future, I can see porting the zlib C code to D and implementing

 directly in std.zlib. But that won't affect the user of std.zlib,



 that it might be a little smaller and faster.



Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bntjhh$1srj$2 digitaldaemon.com...
 One man's hodgepodge is another man's freedom of expression.

Sure. But nobody using D is censored or constrained by the std conventions. D is a multiparadigm language.
 I really don't think obliging people to always favour exceptions is going

 fly. Exception-handling is the emporer's new clothes; nobody dares to

 their qualms. That's not to say I don't use it, or believe it is useful,

 I've got both feet firmly in the Kernighan and Pike camp.

I'm not familiar with the reference.
 Exceptions are for
 exceptional circumstances.

Yes, I agree.
 I don't think all that is error-handling falls
 within that description.

There's certainly a grey area between clear errors and what is expected behavior.
 But, sure, other people have different opinions, and paradigms of work.

 that backs up my argument that we should support multiple programming
 paradigms.

 As to the consistency issue, I think that modules that are exclusively

 functions should not use exceptions for error-handling. Those that are
 class-based are another matter.

Why? Consider std.file.read(). It's a free function that reads the contents of a file into an array. It throws an exception if the file doesn't exist or if the read failed in some way. I use this function all the time, and find it very handy to rely on the exception mechanism to report errors rather than the C way of testing the result every time.
 I see three levels of APIs.

 1. Raw C APIs
 2. D-ified C APIs, and D free functions
 3. Classes

 I am not arguing for much, if any, of 1, but I am arguing strongly that 2

 just as valid as 3.

I think we're misunderstanding each other, then, because I am in full agreement with you there!
Oct 31 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 One man's hodgepodge is another man's freedom of expression.

Sure. But nobody using D is censored or constrained by the std

 D is a multiparadigm language.

Good.
 I really don't think obliging people to always favour exceptions is


 to
 fly. Exception-handling is the emporer's new clothes; nobody dares to

 their qualms. That's not to say I don't use it, or believe it is useful,

 I've got both feet firmly in the Kernighan and Pike camp.

I'm not familiar with the reference.

"The Practise Of Programming", AWL, 1999
 Exceptions are for
 exceptional circumstances.

Yes, I agree.

Cool
 I don't think all that is error-handling falls
 within that description.

There's certainly a grey area between clear errors and what is expected behavior.

Indeed there is, and ...
 But, sure, other people have different opinions, and paradigms of work.

 that backs up my argument that we should support multiple programming
 paradigms.

 As to the consistency issue, I think that modules that are exclusively

 functions should not use exceptions for error-handling. Those that are
 class-based are another matter.

Why? Consider std.file.read(). It's a free function that reads the

 of a file into an array. It throws an exception if the file doesn't exist

 if the read failed in some way. I use this function all the time, and find
 it very handy to rely on the exception mechanism to report errors rather
 than the C way of testing the result every time.

... you cleverly pick an exceptional example that ably demonstrates your point, and slashes mine. :)
 I see three levels of APIs.

 1. Raw C APIs
 2. D-ified C APIs, and D free functions
 3. Classes

 I am not arguing for much, if any, of 1, but I am arguing strongly that


 is
 just as valid as 3.

I think we're misunderstanding each other, then, because I am in full agreement with you there!

Maybe
Oct 31 2003
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <bntd28$1k51$1 digitaldaemon.com>, Walter says...

BTW, the etc.c.zlib is just as usable or unusable as the C zlib library is,
as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib to
figure out what they're good for and how to use them, that's unacceptable),
it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an easy
face on it made sense, and the result is std.zlib.

BTW, have you thougt about making also a zip-file handling library in the D standard libraries? I find this very useful to be included by default in every Java implementation, for example. Ciao P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused, right?
Oct 31 2003
parent "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:bntlcf$1v5t$1 digitaldaemon.com...
 In article <bntd28$1k51$1 digitaldaemon.com>, Walter says...
BTW, the etc.c.zlib is just as usable or unusable as the C zlib library


as that's all it is. I find it more complex than necessary (there are a
number of parameters you basically have to read the source code to zlib


figure out what they're good for and how to use them, that's


it has a bunch of stuff related to storage allocation, and it uses error
codes rather than exceptions. Hence, I decided a D wrapper that put an


face on it made sense, and the result is std.zlib.


 standard libraries?
 I find this very useful to be included by default in every Java

 for example.

Yes, I have thought of it, and I've already implemented std.zip. <g>. It will be in the next release. Great minds think alike!
 P.S.: I deduce that my proposal of renaming etc.* to ext.* was refused,

When I see 'ext' I think 'external'. I kinda like 'etc', it is only 3 letters long and is a very common abbreviation for 'etcetera' and is not likely to be confused with anything else.
Oct 31 2003
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:bnsrb4$h4o$1 digitaldaemon.com: 
 Here's what I did. First, I did a simple module with declarations to
 make the C zlib functions accessible from D. It makes no attempt to
 hide zlib's C conventions. This will not be an official D package, but
 is still useful, so I stuffed it in etc.c.zlib. Then I build a D
 version that implements a conventional D interface to the zlib
 functionality. I called this std.zlib. Now, it works out that std.zlib
 is implemented by calling the functions in etc.c.zlib, but that is
 quite irrelevant to (and hidden from) the user of std.zlib.
 
 In the future, I can see porting the zlib C code to D and implementing
 them directly in std.zlib. But that won't affect the user of std.zlib,
 except that it might be a little smaller and faster.

Why not std.zlib and std.zlib.c? This make more sense to me from a packageing standpoint. Everything needed for the zlib module is in one directory hierarchy instead of two.
Oct 31 2003
parent "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns94255512CA292patcodemooncom 63.105.9.61...
 Why not std.zlib and std.zlib.c?  This make more sense
 to me from a packageing standpoint.  Everything needed for the zlib
 module is in one directory hierarchy instead of two.

Because I don't see the raw zlib interface as being useful enough to be in the std heirarchy. I think of it as "it's there if you want it, but it isn't a core feature of the D library".
Oct 31 2003
prev sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
wrote:

Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide zlib's C
conventions. This will not be an official D package, but is still useful, so
I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this std.zlib.
Now, it works out that std.zlib is implemented by calling the functions in
etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.

This is a big red flag to me. The standard library (std.zlib) is dependant upon something outside of the standard library (etc.c.zlib). As far as I'm concerned, the standard library should be entirely self-contained. It seems to me that if a standard library module needs to depend on a c module, it should be something in std.c rather than in etc.c (maybe we need both std.c and etc.c).
Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:3qf5qv066p5295hqfbo0isgh1c8aeg101f 4ax.com...
 On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
 wrote:
Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide


conventions. This will not be an official D package, but is still useful,


I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this


Now, it works out that std.zlib is implemented by calling the functions


etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.

dependant upon something outside of the standard library (etc.c.zlib). As far as I'm concerned, the standard library should be entirely self-contained.

In general, you're right. But in some cases the implementation should be hidden from the user. The user of std.zlib is not dependent on it.
 It seems to me that if a standard library module needs to depend on a
 c module, it should be something in std.c rather than in etc.c (maybe
 we need both std.c and etc.c).

I don't think it's necessary for the implementation of it to be in std.
Oct 31 2003
parent Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 "Benji Smith" <dlanguage xxagg.com> wrote in message
 news:3qf5qv066p5295hqfbo0isgh1c8aeg101f 4ax.com...
 On Thu, 30 Oct 2003 20:49:12 -0800, "Walter" <walter digitalmars.com>
 wrote:
Here's what I did. First, I did a simple module with declarations to make
the C zlib functions accessible from D. It makes no attempt to hide


conventions. This will not be an official D package, but is still useful,


I stuffed it in etc.c.zlib. Then I build a D version that implements a
conventional D interface to the zlib functionality. I called this


Now, it works out that std.zlib is implemented by calling the functions


etc.c.zlib, but that is quite irrelevant to (and hidden from) the user of
std.zlib.

dependant upon something outside of the standard library (etc.c.zlib). As far as I'm concerned, the standard library should be entirely self-contained.

In general, you're right. But in some cases the implementation should be hidden from the user. The user of std.zlib is not dependent on it.
 It seems to me that if a standard library module needs to depend on a
 c module, it should be something in std.c rather than in etc.c (maybe
 we need both std.c and etc.c).

I don't think it's necessary for the implementation of it to be in std.

But then you talk and build a bigger entity than std. This I called dlib, that which incloses all modules that are downloaded with the standard distribution. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Nov 01 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 You're right, it doesn't matter if the library is implemented in C or D. But
 it *does* matter if it follows C or D conventions. For example, if a module
 uses errno or error numbers, 0 terminated strings, expects the caller to use
 malloc/free on data passed through its interface, etc., I'd prefer to put it
 under a C package so that gives the potential user of it some extra
 notification that it does not follow D conventions.

Good point. This made me think about the following: Is it possible to import a module without adding its symbols directly to the current namespace? Since C functions require different handling than D functions I would like to import such modules in a way so that I have to explicitly type std.c.func() instead of func(). Just as a reminder to myself and the people reading my code that one has to take care how to use them. This would be especially important for string functions, I expect, since forgetting to add the null-terminator can cause a crash. Any way to do this? Hauke
Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bntgtv$1pdn$1 digitaldaemon.com...
 Good point. This made me think about the following:

 Is it possible to import a module without adding its symbols directly to
 the current namespace?

 Since C functions require different handling than D functions I would
 like to import such modules in a way so that I have to explicitly type
 std.c.func() instead of func(). Just as a reminder to myself and the
 people reading my code that one has to take care how to use them.

 This would be especially important for string functions, I expect, since
   forgetting to add the null-terminator can cause a crash.

 Any way to do this?

No, there currently isn't a way to do that. BTW, import doesn't exactly add a symbol to the current namespace, it just adds a search of the import module if the name isn't already in the current namespace. In other words, any names in the current namespace override imported names. Hmm, that does suggest a way to do it ... define a bunch of dummy symbols with the same name, then anyone using the import will be forced to qualify it!
Oct 31 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
Since C functions require different handling than D functions I would
like to import such modules in a way so that I have to explicitly type
std.c.func() instead of func(). Just as a reminder to myself and the
people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since
  forgetting to add the null-terminator can cause a crash.

Any way to do this?

No, there currently isn't a way to do that. BTW, import doesn't exactly add a symbol to the current namespace, it just adds a search of the import module if the name isn't already in the current namespace. In other words, any names in the current namespace override imported names. Hmm, that does suggest a way to do it ... define a bunch of dummy symbols with the same name, then anyone using the import will be forced to qualify it!

You mean like this? import std.c.stdio; int printf; int scanf; int fopen; int fread; [snipped about a hundred further definitions] Every time I import std.c.stdio? That isn't really practical ;). I know you're probably sick of all these feature requests, but don't you think there should be an EASY way to do such an import? Maybe something like "use std.c.stdio;" / "using std.c.stdio" or "reference std.c.stdio;" or "access std.c.stdio;" which would mean that the current module accesses the specified module, but the symbols are not "imported" and must be references using fully qualified names. Maybe this could also be done by adding a new feature to import. Like the ability to specify an alias for the imported module's namespace. For example: import std.c.stdio as c; If the "as" part is left out the symbols are added to the current namespace (or, as you put it, an automatic search for that namespace is added to the current namespace). Otherwise they are added to a namespace with the specified name. So one would have to write "c.printf" instead of just "printf", which is just what I want: it is obvious that a C function is called, so I am reminded to zero-terminate strings, for example. This could also be useful to "flatten" deep module hierarchies. If one uses two modules that define the same symbols, one has to use fully qualified names, right? With such an "import as" you could do the following: import foo.bar.flobbox.windows.henry as henry; import foo_version2.bar.flobbox.windows.henry as henry2; Then you could write henry.someFunc(); and henry2.someFunc(); instead of foo.bar.flobbox.windows.henry.someFunc(); foo_version2.bar.flobbox.windows.henry.someFunc(); Could come in handy... Hauke
Oct 31 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnup38$g4e$1 digitaldaemon.com...
 Walter wrote:
Since C functions require different handling than D functions I would
like to import such modules in a way so that I have to explicitly type
std.c.func() instead of func(). Just as a reminder to myself and the
people reading my code that one has to take care how to use them.

This would be especially important for string functions, I expect, since
  forgetting to add the null-terminator can cause a crash.

Any way to do this?

No, there currently isn't a way to do that. BTW, import doesn't exactly


 a symbol to the current namespace, it just adds a search of the import
 module if the name isn't already in the current namespace. In other


 any names in the current namespace override imported names.

 Hmm, that does suggest a way to do it ... define a bunch of dummy


 with the same name, then anyone using the import will be forced to


 it!

You mean like this? import std.c.stdio; int printf; int scanf; int fopen; int fread; [snipped about a hundred further definitions] Every time I import std.c.stdio? That isn't really practical ;).

I assumed Walter was talking about internal to the compiler. It would indeed be worrying if he meant your interpretation. Big W, say it ain't so!
Oct 31 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnup38$g4e$1 digitaldaemon.com...
 Hmm, that does suggest a way to do it ... define a bunch of dummy


 with the same name, then anyone using the import will be forced to


 it!

You mean like this? import std.c.stdio; int printf; int scanf; int fopen; int fread; [snipped about a hundred further definitions] Every time I import std.c.stdio? That isn't really practical ;).

I know. It's just a thought.
 I know you're probably sick of all these feature requests, but don't you
 think there should be an EASY way to do such an import?

 Maybe something like

 "use std.c.stdio;" / "using std.c.stdio"

 or

 "reference std.c.stdio;"

 or

 "access std.c.stdio;"

 which would mean that the current module accesses the specified module,
 but the symbols are not "imported" and must be references using fully
 qualified names.

I understand what you're looking for. I'm not ready to implement that yet, though. Too many other things first!
 Maybe this could also be done by adding a new feature to import. Like
 the ability to specify an alias for the imported module's namespace.

 For example:

 import std.c.stdio as c;

 If the "as" part is left out the symbols are added to the current
 namespace (or, as you put it, an automatic search for that namespace is
 added to the current namespace). Otherwise they are added to a namespace
 with the specified name. So one would have to write "c.printf" instead
 of just "printf", which is just what I want: it is obvious that a C
 function is called, so I am reminded to zero-terminate strings, for

 This could also be useful to "flatten" deep module hierarchies. If one
 uses two modules that define the same symbols, one has to use fully
 qualified names, right? With such an "import as" you could do the

 import foo.bar.flobbox.windows.henry as henry;
 import foo_version2.bar.flobbox.windows.henry as henry2;

 Then you could write

 henry.someFunc();
 and
 henry2.someFunc();

 instead of

 foo.bar.flobbox.windows.henry.someFunc();
 foo_version2.bar.flobbox.windows.henry.someFunc();

 Could come in handy...

The alias already works for module names: import foo.bar.abc; alias foo.bar.abc xyz; ... xyz.func();
Oct 31 2003
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.

Do you mean: ########################## std |-- c | |-- process.d | |-- stdio.d | `-- stdlib.d |-- etc |-- internal | |-- aaA.d | |-- achar.d | |-- adi.d | |-- alloca.d | |-- array.d | |-- arraycast.d | |-- arraycat.d | |-- assert.d | |-- cast.d | |-- critical.c | |-- dmain2.d | |-- errno.c | |-- gc.d | |-- gc2 | |-- gcstats.d | |-- intrinsic.d | |-- invariant.d | |-- llmath.d | |-- mars.h | |-- memset.d | |-- minit.asm | |-- moduleinit.d | |-- monitor.c | |-- obj.d | |-- object.d | |-- outofmemory.d | |-- switch.d | `-- switcherr.d |-- os | |-- linux | | |-- linux.d | | `-- linuxextern.d | |-- windows | | |-- com.d | | |-- iunknown.d | | |-- registry.d | | |-- syserror.d | | `-- windows.d | |-- date.d | |-- file.d | |-- path.d | |-- system.d | |-- thread.d | `-- time.d |-- typeinfo | |-- ti_AC.d | |-- ti_Aa.d | |-- ti_Adchar.d | |-- ti_Ag.d | |-- ti_Aint.d | |-- ti_Along.d | |-- ti_Ashort.d | |-- ti_Aubyte.d | |-- ti_Auint.d | |-- ti_Aulong.d | |-- ti_Aushort.d | |-- ti_Awchar.d | |-- ti_C.d | |-- ti_byte.d | |-- ti_cdouble.d | |-- ti_cfloat.d | |-- ti_char.d | |-- ti_creal.d | |-- ti_dchar.d | |-- ti_delegate.d | |-- ti_double.d | |-- ti_extended.d | |-- ti_float.d | |-- ti_idouble.d | |-- ti_ifloat.d | |-- ti_int.d | |-- ti_ireal.d | |-- ti_long.d | |-- ti_ptr.d | |-- ti_real.d | |-- ti_short.d | |-- ti_ubyte.d | |-- ti_uint.d | |-- ti_ulong.d | |-- ti_ushort.d | `-- ti_wchar.d |-- cmath2.d |-- compiler.d |-- complex.c |-- conv.d |-- crc32.d |-- ctype.d |-- dateparse.d |-- deh.c |-- deh2.d |-- linux.mak |-- math.d |-- math2.d |-- outbuffer.d |-- qsort.d |-- random.d |-- regexp.d |-- stdint.d |-- stream.d |-- string.d |-- unittest.d |-- uri.d |-- utf.d `-- win32.mak 7 directories, 103 files ########################## would makefiles for this be a good thing? would a conversion for existing source files be a good thing (same type as the makePrivate I made) ? Ant
Oct 30 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
That looks mostly right. Conversion of source would be a bit of a pain, but
not too bad. I have a program that can do global search/replace across
files.

"Ant" <Ant_member pathlink.com> wrote in message
news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.

Do you mean: ########################## std |-- c | |-- process.d | |-- stdio.d | `-- stdlib.d |-- etc |-- internal | |-- aaA.d | |-- achar.d | |-- adi.d | |-- alloca.d | |-- array.d | |-- arraycast.d | |-- arraycat.d | |-- assert.d | |-- cast.d | |-- critical.c | |-- dmain2.d | |-- errno.c | |-- gc.d | |-- gc2 | |-- gcstats.d | |-- intrinsic.d | |-- invariant.d | |-- llmath.d | |-- mars.h | |-- memset.d | |-- minit.asm | |-- moduleinit.d | |-- monitor.c | |-- obj.d | |-- object.d | |-- outofmemory.d | |-- switch.d | `-- switcherr.d |-- os | |-- linux | | |-- linux.d | | `-- linuxextern.d | |-- windows | | |-- com.d | | |-- iunknown.d | | |-- registry.d | | |-- syserror.d | | `-- windows.d | |-- date.d | |-- file.d | |-- path.d | |-- system.d | |-- thread.d | `-- time.d |-- typeinfo | |-- ti_AC.d | |-- ti_Aa.d | |-- ti_Adchar.d | |-- ti_Ag.d | |-- ti_Aint.d | |-- ti_Along.d | |-- ti_Ashort.d | |-- ti_Aubyte.d | |-- ti_Auint.d | |-- ti_Aulong.d | |-- ti_Aushort.d | |-- ti_Awchar.d | |-- ti_C.d | |-- ti_byte.d | |-- ti_cdouble.d | |-- ti_cfloat.d | |-- ti_char.d | |-- ti_creal.d | |-- ti_dchar.d | |-- ti_delegate.d | |-- ti_double.d | |-- ti_extended.d | |-- ti_float.d | |-- ti_idouble.d | |-- ti_ifloat.d | |-- ti_int.d | |-- ti_ireal.d | |-- ti_long.d | |-- ti_ptr.d | |-- ti_real.d | |-- ti_short.d | |-- ti_ubyte.d | |-- ti_uint.d | |-- ti_ulong.d | |-- ti_ushort.d | `-- ti_wchar.d |-- cmath2.d |-- compiler.d |-- complex.c |-- conv.d |-- crc32.d |-- ctype.d |-- dateparse.d |-- deh.c |-- deh2.d |-- linux.mak |-- math.d |-- math2.d |-- outbuffer.d |-- qsort.d |-- random.d |-- regexp.d |-- stdint.d |-- stream.d |-- string.d |-- unittest.d |-- uri.d |-- utf.d `-- win32.mak 7 directories, 103 files ########################## would makefiles for this be a good thing? would a conversion for existing source files be a good thing (same type as the makePrivate I made) ? Ant

Oct 30 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bnseuj$2t1h$2 digitaldaemon.com>, Walter says...
That looks mostly right. Conversion of source would be a bit of a pain, but
not too bad. I have a program that can do global search/replace across
files.

Just forgot to create the gc2 dir. All gc2 stuff will go under std.internal.gc2 (?). To convert existing sources I was thinking of a makefile with something like: FILES=$(wildcard *.d) $(FILES): sed -e 's/import com;/import os\.windows\.com;/g' \ $ > $(NEW_LOCATION)/$ (unless your program is better) that worked to convert all "import" in phobos to "private import" Ant
Oct 30 2003
parent "Walter" <walter digitalmars.com> writes:
I don't have sed, but yeah, something like that should cover about 90% of
the work. std.internal.gc is probably the right place for the gc
implementation.

"Ant" <Ant_member pathlink.com> wrote in message
news:bnshaa$30cd$1 digitaldaemon.com...
 In article <bnseuj$2t1h$2 digitaldaemon.com>, Walter says...
That looks mostly right. Conversion of source would be a bit of a pain,


not too bad. I have a program that can do global search/replace across
files.

Just forgot to create the gc2 dir. All gc2 stuff will go under std.internal.gc2 (?). To convert existing sources I was thinking of a makefile with something like: FILES=$(wildcard *.d) $(FILES): sed -e 's/import com;/import os\.windows\.com;/g' \ $ > $(NEW_LOCATION)/$ (unless your program is better) that worked to convert all "import" in phobos to "private import" Ant

Oct 30 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
What program ?

Also , I keep hitting my head on the toStringz for std.c.X stuff, what about
a std.d.X that mirrors std.c and handles char []  and the like ?

C

"Walter" <walter digitalmars.com> wrote in message
news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a pain,

 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just



one of the right answers.

Do you mean: ########################## std |-- c | |-- process.d | |-- stdio.d | `-- stdlib.d |-- etc |-- internal | |-- aaA.d | |-- achar.d | |-- adi.d | |-- alloca.d | |-- array.d | |-- arraycast.d | |-- arraycat.d | |-- assert.d | |-- cast.d | |-- critical.c | |-- dmain2.d | |-- errno.c | |-- gc.d | |-- gc2 | |-- gcstats.d | |-- intrinsic.d | |-- invariant.d | |-- llmath.d | |-- mars.h | |-- memset.d | |-- minit.asm | |-- moduleinit.d | |-- monitor.c | |-- obj.d | |-- object.d | |-- outofmemory.d | |-- switch.d | `-- switcherr.d |-- os | |-- linux | | |-- linux.d | | `-- linuxextern.d | |-- windows | | |-- com.d | | |-- iunknown.d | | |-- registry.d | | |-- syserror.d | | `-- windows.d | |-- date.d | |-- file.d | |-- path.d | |-- system.d | |-- thread.d | `-- time.d |-- typeinfo | |-- ti_AC.d | |-- ti_Aa.d | |-- ti_Adchar.d | |-- ti_Ag.d | |-- ti_Aint.d | |-- ti_Along.d | |-- ti_Ashort.d | |-- ti_Aubyte.d | |-- ti_Auint.d | |-- ti_Aulong.d | |-- ti_Aushort.d | |-- ti_Awchar.d | |-- ti_C.d | |-- ti_byte.d | |-- ti_cdouble.d | |-- ti_cfloat.d | |-- ti_char.d | |-- ti_creal.d | |-- ti_dchar.d | |-- ti_delegate.d | |-- ti_double.d | |-- ti_extended.d | |-- ti_float.d | |-- ti_idouble.d | |-- ti_ifloat.d | |-- ti_int.d | |-- ti_ireal.d | |-- ti_long.d | |-- ti_ptr.d | |-- ti_real.d | |-- ti_short.d | |-- ti_ubyte.d | |-- ti_uint.d | |-- ti_ulong.d | |-- ti_ushort.d | `-- ti_wchar.d |-- cmath2.d |-- compiler.d |-- complex.c |-- conv.d |-- crc32.d |-- ctype.d |-- dateparse.d |-- deh.c |-- deh2.d |-- linux.mak |-- math.d |-- math2.d |-- outbuffer.d |-- qsort.d |-- random.d |-- regexp.d |-- stdint.d |-- stream.d |-- string.d |-- unittest.d |-- uri.d |-- utf.d `-- win32.mak 7 directories, 103 files ########################## would makefiles for this be a good thing? would a conversion for existing source files be a good thing (same type as the makePrivate I made) ? Ant


Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
I'll include it (replace.exe) in the next release.

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnu9tf$2sa9$1 digitaldaemon.com...
 What program ?

 Also , I keep hitting my head on the toStringz for std.c.X stuff, what

 a std.d.X that mirrors std.c and handles char []  and the like ?

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a pain,

 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just



one of the right answers.

Do you mean: ########################## std |-- c | |-- process.d | |-- stdio.d | `-- stdlib.d |-- etc |-- internal | |-- aaA.d | |-- achar.d | |-- adi.d | |-- alloca.d | |-- array.d | |-- arraycast.d | |-- arraycat.d | |-- assert.d | |-- cast.d | |-- critical.c | |-- dmain2.d | |-- errno.c | |-- gc.d | |-- gc2 | |-- gcstats.d | |-- intrinsic.d | |-- invariant.d | |-- llmath.d | |-- mars.h | |-- memset.d | |-- minit.asm | |-- moduleinit.d | |-- monitor.c | |-- obj.d | |-- object.d | |-- outofmemory.d | |-- switch.d | `-- switcherr.d |-- os | |-- linux | | |-- linux.d | | `-- linuxextern.d | |-- windows | | |-- com.d | | |-- iunknown.d | | |-- registry.d | | |-- syserror.d | | `-- windows.d | |-- date.d | |-- file.d | |-- path.d | |-- system.d | |-- thread.d | `-- time.d |-- typeinfo | |-- ti_AC.d | |-- ti_Aa.d | |-- ti_Adchar.d | |-- ti_Ag.d | |-- ti_Aint.d | |-- ti_Along.d | |-- ti_Ashort.d | |-- ti_Aubyte.d | |-- ti_Auint.d | |-- ti_Aulong.d | |-- ti_Aushort.d | |-- ti_Awchar.d | |-- ti_C.d | |-- ti_byte.d | |-- ti_cdouble.d | |-- ti_cfloat.d | |-- ti_char.d | |-- ti_creal.d | |-- ti_dchar.d | |-- ti_delegate.d | |-- ti_double.d | |-- ti_extended.d | |-- ti_float.d | |-- ti_idouble.d | |-- ti_ifloat.d | |-- ti_int.d | |-- ti_ireal.d | |-- ti_long.d | |-- ti_ptr.d | |-- ti_real.d | |-- ti_short.d | |-- ti_ubyte.d | |-- ti_uint.d | |-- ti_ulong.d | |-- ti_ushort.d | `-- ti_wchar.d |-- cmath2.d |-- compiler.d |-- complex.c |-- conv.d |-- crc32.d |-- ctype.d |-- dateparse.d |-- deh.c |-- deh2.d |-- linux.mak |-- math.d |-- math2.d |-- outbuffer.d |-- qsort.d |-- random.d |-- regexp.d |-- stdint.d |-- stream.d |-- string.d |-- unittest.d |-- uri.d |-- utf.d `-- win32.mak 7 directories, 103 files ########################## would makefiles for this be a good thing? would a conversion for existing source files be a good thing (same type as the makePrivate I made) ? Ant



Oct 31 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Is it written in D?

"Walter" <walter digitalmars.com> wrote in message
news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.

 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bnu9tf$2sa9$1 digitaldaemon.com...
 What program ?

 Also , I keep hitting my head on the toStringz for std.c.X stuff, what

 a std.d.X that mirrors std.c and handles char []  and the like ?

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:bnseuj$2t1h$2 digitaldaemon.com...
 That looks mostly right. Conversion of source would be a bit of a



 but
 not too bad. I have a program that can do global search/replace across
 files.

 "Ant" <Ant_member pathlink.com> wrote in message
 news:bnsadc$2mk7$1 digitaldaemon.com...
 In article <bnn9a0$1o09$1 digitaldaemon.com>, Walter says...
There have been a lot of good ideas and points made about this in





discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to





 pick
one of the right answers.

Do you mean: ########################## std |-- c | |-- process.d | |-- stdio.d | `-- stdlib.d |-- etc |-- internal | |-- aaA.d | |-- achar.d | |-- adi.d | |-- alloca.d | |-- array.d | |-- arraycast.d | |-- arraycat.d | |-- assert.d | |-- cast.d | |-- critical.c | |-- dmain2.d | |-- errno.c | |-- gc.d | |-- gc2 | |-- gcstats.d | |-- intrinsic.d | |-- invariant.d | |-- llmath.d | |-- mars.h | |-- memset.d | |-- minit.asm | |-- moduleinit.d | |-- monitor.c | |-- obj.d | |-- object.d | |-- outofmemory.d | |-- switch.d | `-- switcherr.d |-- os | |-- linux | | |-- linux.d | | `-- linuxextern.d | |-- windows | | |-- com.d | | |-- iunknown.d | | |-- registry.d | | |-- syserror.d | | `-- windows.d | |-- date.d | |-- file.d | |-- path.d | |-- system.d | |-- thread.d | `-- time.d |-- typeinfo | |-- ti_AC.d | |-- ti_Aa.d | |-- ti_Adchar.d | |-- ti_Ag.d | |-- ti_Aint.d | |-- ti_Along.d | |-- ti_Ashort.d | |-- ti_Aubyte.d | |-- ti_Auint.d | |-- ti_Aulong.d | |-- ti_Aushort.d | |-- ti_Awchar.d | |-- ti_C.d | |-- ti_byte.d | |-- ti_cdouble.d | |-- ti_cfloat.d | |-- ti_char.d | |-- ti_creal.d | |-- ti_dchar.d | |-- ti_delegate.d | |-- ti_double.d | |-- ti_extended.d | |-- ti_float.d | |-- ti_idouble.d | |-- ti_ifloat.d | |-- ti_int.d | |-- ti_ireal.d | |-- ti_long.d | |-- ti_ptr.d | |-- ti_real.d | |-- ti_short.d | |-- ti_ubyte.d | |-- ti_uint.d | |-- ti_ulong.d | |-- ti_ushort.d | `-- ti_wchar.d |-- cmath2.d |-- compiler.d |-- complex.c |-- conv.d |-- crc32.d |-- ctype.d |-- dateparse.d |-- deh.c |-- deh2.d |-- linux.mak |-- math.d |-- math2.d |-- outbuffer.d |-- qsort.d |-- random.d |-- regexp.d |-- stdint.d |-- stream.d |-- string.d |-- unittest.d |-- uri.d |-- utf.d `-- win32.mak 7 directories, 103 files ########################## would makefiles for this be a good thing? would a conversion for existing source files be a good thing (same type as the makePrivate I made) ? Ant




Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
I wrote it eons ago, so it's in C. It's a completely trivial program, but I
find myself using it all the time. I'll post the source here. I think a D
version would be an improvement; anyone want to give it a go?

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.


------------------------------------------------------------------- /*_ replace.c Mon Nov 21 1988 Modified by: Walter Bright */ #include <stdio.h> #include <string.h> #include <stdlib.h> #include <dos.h> EXPAND_WILDCARDS; #include "filespec.h" #define STRMAX 80 char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1]; char *ptrd, *ptri, *strptr; FILE *fpin, *fpout; unsigned long int strcount; int cc; main(argc, argv) int argc; char *argv[]; { int i; int result = 0; unsigned len; char *sourcename,*backupname; if(argc < 2) { fputs ("Usage:\n\treplace filename(s)", stdout); exit (1); } fputs("String to be replaced (80 characters max)?\n",stdout); fgets(oldstr, STRMAX + 1, stdin); fputs("Replacement string?\n", stdout); fgets(newstr, STRMAX + 1, stdin); /* Kill the CR and LF at the end of the strings. */ for(ptrd = newstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n' ) *ptrd = '\0'; } for(ptrd = oldstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n') *ptrd = '\0'; } strcount = 0L; for (i = 1; i < argc; i++) { char *tempname; sourcename = argv[i]; fputs("File ",stdout); fputs(sourcename,stdout); fputc('\n',stdout); tempname = filespecforceext(sourcename,"tmp"); backupname = filespecforceext(sourcename,"bak"); fpout = fopen(tempname, "w"); if (!fpout) { fputs("cannot open ",stdout); fputs(sourcename, stdout); fputc('\n',stdout); continue; } fpin = fopen(sourcename, "r"); if (!fpin) { fputs("cannot open ",stdout); fputs(backupname, stdout); fputc('\n',stdout); fclose (fpout); continue; } if (replace()) { unlink (backupname); /* Delete any existing backup. */ if (rename (sourcename, backupname) == -1 || rename (tempname, sourcename) == -1) { fputs ("File rename error with file '", stdout); fputs (sourcename, stdout); fputs ("'\n", stdout); } } else { fputs("No changes\n",stdout); unlink(tempname); } free(backupname); free(tempname); outascii (strcount); fputs (" strings replaced\n", stdout); strcount = 0L; } return result; } outascii (n) unsigned long int n; { char outstr[16], *ptr; outstr[15] = '\0'; ptr = &outstr[14]; do { *ptr-- = (char)('0' + n % 10); n /= 10; } while (n); fputs (ptr + 1, stdout); } /******************************* * Does the actual replacement. * Returns: * 0 error or no changes made */ int replace () { int sflag; if (*oldstr) /* If there is a char, search for strings. */ { for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() ) { /* Compare the two strings for a match. If it doesn't fully match then shift the input string over and continue (case 0). If it fully matches then replace the string (case 1). If EOF occurs then exit (case -1). */ if (sflag) { *instr = '\0'; if (fputs (newstr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } strcount++; } else { if (putc (*instr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } /* Shift the string. */ for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ = *ptri++); *strptr = '\0'; } } } if (fclose(fpin) == EOF || fclose(fpout) == EOF) { fputs("Error closing files\n",stdout); goto err; } return strcount != 0; err: return 0; } /**************************************** * Inputs characters to the input string, checks the input string for a match * against the dead string. */ strcheck() { ptrd = oldstr; ptri = instr; while( *ptri == *ptrd && *ptrd != '\0' ) { ptrd++; ptri++; } if( *ptri == '\0' && *ptrd != '\0' ) { while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' ) *ptri++ = cc; if( cc == EOF ) { *ptri++ = '\0'; return -1; } *ptri++ = cc; *ptri++ = '\0'; } if( *ptrd != '\0' ) return 0; /* Doesn't fully match the input string. */ else return 1; /* Full match. */ } #define MEM_H #define mem_malloc malloc #define mem_strdup strdup #define mem_free free #define mem_calloc(n) calloc(n,1) #include "filespec.c"
Oct 31 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Sure ill go for it, is their an ETA for .75 ?  I ask because of the private
imports, and some other changes requested for phobos that we'd like to
implement, but if .75 is available soon ill just wait.

C

"Walter" <walter digitalmars.com> wrote in message
news:bnupcl$gjs$1 digitaldaemon.com...
 I wrote it eons ago, so it's in C. It's a completely trivial program, but

 find myself using it all the time. I'll post the source here. I think a D
 version would be an improvement; anyone want to give it a go?

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.


------------------------------------------------------------------- /*_ replace.c Mon Nov 21 1988 Modified by: Walter Bright */ #include <stdio.h> #include <string.h> #include <stdlib.h> #include <dos.h> EXPAND_WILDCARDS; #include "filespec.h" #define STRMAX 80 char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1]; char *ptrd, *ptri, *strptr; FILE *fpin, *fpout; unsigned long int strcount; int cc; main(argc, argv) int argc; char *argv[]; { int i; int result = 0; unsigned len; char *sourcename,*backupname; if(argc < 2) { fputs ("Usage:\n\treplace filename(s)", stdout); exit (1); } fputs("String to be replaced (80 characters max)?\n",stdout); fgets(oldstr, STRMAX + 1, stdin); fputs("Replacement string?\n", stdout); fgets(newstr, STRMAX + 1, stdin); /* Kill the CR and LF at the end of the strings. */ for(ptrd = newstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n' ) *ptrd = '\0'; } for(ptrd = oldstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n') *ptrd = '\0'; } strcount = 0L; for (i = 1; i < argc; i++) { char *tempname; sourcename = argv[i]; fputs("File ",stdout); fputs(sourcename,stdout); fputc('\n',stdout); tempname = filespecforceext(sourcename,"tmp"); backupname = filespecforceext(sourcename,"bak"); fpout = fopen(tempname, "w"); if (!fpout) { fputs("cannot open ",stdout); fputs(sourcename, stdout); fputc('\n',stdout); continue; } fpin = fopen(sourcename, "r"); if (!fpin) { fputs("cannot open ",stdout); fputs(backupname, stdout); fputc('\n',stdout); fclose (fpout); continue; } if (replace()) { unlink (backupname); /* Delete any existing backup. */ if (rename (sourcename, backupname) == -1 || rename (tempname, sourcename) == -1) { fputs ("File rename error with file '", stdout); fputs (sourcename, stdout); fputs ("'\n", stdout); } } else { fputs("No changes\n",stdout); unlink(tempname); } free(backupname); free(tempname); outascii (strcount); fputs (" strings replaced\n", stdout); strcount = 0L; } return result; } outascii (n) unsigned long int n; { char outstr[16], *ptr; outstr[15] = '\0'; ptr = &outstr[14]; do { *ptr-- = (char)('0' + n % 10); n /= 10; } while (n); fputs (ptr + 1, stdout); } /******************************* * Does the actual replacement. * Returns: * 0 error or no changes made */ int replace () { int sflag; if (*oldstr) /* If there is a char, search for strings. */ { for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() ) { /* Compare the two strings for a match. If it doesn't fully match then shift the input string over and continue (case 0). If it fully matches then replace the string (case 1). If EOF occurs then exit (case -1). */ if (sflag) { *instr = '\0'; if (fputs (newstr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } strcount++; } else { if (putc (*instr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } /* Shift the string. */ for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ =

         *strptr = '\0';
       }
     }
   }
     if (fclose(fpin) == EOF || fclose(fpout) == EOF)
     { fputs("Error closing files\n",stdout);
  goto err;
     }
     return strcount != 0;

 err:
     return 0;
 }

 /****************************************
  * Inputs characters to the input string, checks the input string for a
 match
  * against the dead string.
  */

 strcheck()
 {
   ptrd = oldstr;
   ptri = instr;
   while( *ptri == *ptrd && *ptrd != '\0' )
   {
     ptrd++;
     ptri++;
   }
   if( *ptri == '\0' && *ptrd != '\0' )
   {
     while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' )
       *ptri++ = cc;
     if( cc == EOF )
     {
       *ptri++ = '\0';
       return -1;
     }
     *ptri++ = cc;
     *ptri++ = '\0';
   }
   if( *ptrd != '\0' )
     return 0; /* Doesn't fully match the input string. */
   else
     return 1;  /* Full match. */
 }

 #define MEM_H
 #define mem_malloc malloc
 #define mem_strdup strdup
 #define mem_free free
 #define mem_calloc(n) calloc(n,1)

 #include "filespec.c"

Oct 31 2003
parent "Walter" <walter digitalmars.com> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2il$t3j$1 digitaldaemon.com...
 Sure ill go for it, is their an ETA for .75 ?  I ask because of the

 imports, and some other changes requested for phobos that we'd like to
 implement, but if .75 is available soon ill just wait.

I hope to get it done within a week.
Oct 31 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
1988 lol!  man that is old. ( puttin on I think we're alone now : Tiffany )

C

"Walter" <walter digitalmars.com> wrote in message
news:bnupcl$gjs$1 digitaldaemon.com...
 I wrote it eons ago, so it's in C. It's a completely trivial program, but

 find myself using it all the time. I'll post the source here. I think a D
 version would be an improvement; anyone want to give it a go?

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnuo8v$f68$1 digitaldaemon.com...
 Is it written in D?

 "Walter" <walter digitalmars.com> wrote in message
 news:bnun89$dpa$2 digitaldaemon.com...
 I'll include it (replace.exe) in the next release.


------------------------------------------------------------------- /*_ replace.c Mon Nov 21 1988 Modified by: Walter Bright */ #include <stdio.h> #include <string.h> #include <stdlib.h> #include <dos.h> EXPAND_WILDCARDS; #include "filespec.h" #define STRMAX 80 char instr[STRMAX + 1], newstr[STRMAX + 1], oldstr[STRMAX + 1]; char *ptrd, *ptri, *strptr; FILE *fpin, *fpout; unsigned long int strcount; int cc; main(argc, argv) int argc; char *argv[]; { int i; int result = 0; unsigned len; char *sourcename,*backupname; if(argc < 2) { fputs ("Usage:\n\treplace filename(s)", stdout); exit (1); } fputs("String to be replaced (80 characters max)?\n",stdout); fgets(oldstr, STRMAX + 1, stdin); fputs("Replacement string?\n", stdout); fgets(newstr, STRMAX + 1, stdin); /* Kill the CR and LF at the end of the strings. */ for(ptrd = newstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n' ) *ptrd = '\0'; } for(ptrd = oldstr; *ptrd; ptrd++) { if(*ptrd == '\r' || *ptrd == '\n') *ptrd = '\0'; } strcount = 0L; for (i = 1; i < argc; i++) { char *tempname; sourcename = argv[i]; fputs("File ",stdout); fputs(sourcename,stdout); fputc('\n',stdout); tempname = filespecforceext(sourcename,"tmp"); backupname = filespecforceext(sourcename,"bak"); fpout = fopen(tempname, "w"); if (!fpout) { fputs("cannot open ",stdout); fputs(sourcename, stdout); fputc('\n',stdout); continue; } fpin = fopen(sourcename, "r"); if (!fpin) { fputs("cannot open ",stdout); fputs(backupname, stdout); fputc('\n',stdout); fclose (fpout); continue; } if (replace()) { unlink (backupname); /* Delete any existing backup. */ if (rename (sourcename, backupname) == -1 || rename (tempname, sourcename) == -1) { fputs ("File rename error with file '", stdout); fputs (sourcename, stdout); fputs ("'\n", stdout); } } else { fputs("No changes\n",stdout); unlink(tempname); } free(backupname); free(tempname); outascii (strcount); fputs (" strings replaced\n", stdout); strcount = 0L; } return result; } outascii (n) unsigned long int n; { char outstr[16], *ptr; outstr[15] = '\0'; ptr = &outstr[14]; do { *ptr-- = (char)('0' + n % 10); n /= 10; } while (n); fputs (ptr + 1, stdout); } /******************************* * Does the actual replacement. * Returns: * 0 error or no changes made */ int replace () { int sflag; if (*oldstr) /* If there is a char, search for strings. */ { for (*instr = '\0', sflag= strcheck(); sflag >= 0; sflag= strcheck() ) { /* Compare the two strings for a match. If it doesn't fully match then shift the input string over and continue (case 0). If it fully matches then replace the string (case 1). If EOF occurs then exit (case -1). */ if (sflag) { *instr = '\0'; if (fputs (newstr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } strcount++; } else { if (putc (*instr, fpout) == EOF) { fputs("Error writing file\n",stdout); goto err; } /* Shift the string. */ for (strptr = instr, ptri = instr + 1; *ptri; *strptr++ =

         *strptr = '\0';
       }
     }
   }
     if (fclose(fpin) == EOF || fclose(fpout) == EOF)
     { fputs("Error closing files\n",stdout);
  goto err;
     }
     return strcount != 0;

 err:
     return 0;
 }

 /****************************************
  * Inputs characters to the input string, checks the input string for a
 match
  * against the dead string.
  */

 strcheck()
 {
   ptrd = oldstr;
   ptri = instr;
   while( *ptri == *ptrd && *ptrd != '\0' )
   {
     ptrd++;
     ptri++;
   }
   if( *ptri == '\0' && *ptrd != '\0' )
   {
     while( (cc = getc( fpin )) != EOF && cc == *ptrd && *++ptrd != '\0' )
       *ptri++ = cc;
     if( cc == EOF )
     {
       *ptri++ = '\0';
       return -1;
     }
     *ptri++ = cc;
     *ptri++ = '\0';
   }
   if( *ptrd != '\0' )
     return 0; /* Doesn't fully match the input string. */
   else
     return 1;  /* Full match. */
 }

 #define MEM_H
 #define mem_malloc malloc
 #define mem_strdup strdup
 #define mem_free free
 #define mem_calloc(n) calloc(n,1)

 #include "filespec.c"

Oct 31 2003
next sibling parent "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2su$ths$1 digitaldaemon.com...
 1988 lol!  man that is old. ( puttin on I think we're alone now :

 C

Oct 31 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnv2su$ths$1 digitaldaemon.com...
 1988 lol!  man that is old. ( puttin on I think we're alone now :

If you want to see some really old stuff I wrote, check out www.classicempire.com <g>. I think some of my code has wound up in the PDP-10 museum.
Oct 31 2003
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d

So, I made a script to move the lib files to the new structure. I started to split the linux.mak and I'm planing to create a couple of makefiles (or scripts) to: - change the module declarations. - change the import statments (should work both for the lib and apps) Please stop me if it's not usefull! All this on linux. I guess most of the conversions can be run on linux and then the windows.mak would be easy to change either from the old version or the new linux version (?). windows users without make or sed are doomed as they will have to convert their applications some other way. I don't know if it possible to have a phobos set of files with just the import statments - for instance phobos/string.d would be just: /*public*/ import std.string; that would keep things going for existing applications. BTW are we going to make all imports on the lib "private"? (I already posted a makefile that does that) Ant
Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bnu9fa$2roo$1 digitaldaemon.com...
 In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d

So, I made a script to move the lib files to the new structure. I started to split the linux.mak and I'm planing to create a couple of makefiles (or scripts) to: - change the module declarations. - change the import statments (should work both for the lib and apps) Please stop me if it's not usefull!

I've already done most of it!
 All this on linux. I guess most of the conversions can be run
 on linux and then the windows.mak would be easy to change
 either from the old version or the new linux version (?).
 windows users without make or sed are doomed as they will have to
 convert their applications some other way.

 I don't know if it possible to have a phobos set of files with just
 the import statments - for instance phobos/string.d would be just:
 /*public*/ import std.string;

 that would keep things going for existing applications.

That might be a good idea. On the other hand, it just delays the inevitable <g>.
 BTW are we going to make all imports on the lib "private"?
 (I already posted a makefile that does that)

Yes.
Oct 31 2003
parent Ant <Ant_member pathlink.com> writes:
In article <bnun8a$dpa$3 digitaldaemon.com>, Walter says...
"Ant" <Ant_member pathlink.com> wrote in message
news:bnu9fa$2roo$1 digitaldaemon.com...
 In article <bnsadc$2mk7$1 digitaldaemon.com>, Ant says...
std
|-- c
|   |-- process.d
|   |-- stdio.d
|   `-- stdlib.d
|-- etc
|-- internal
|   |-- aaA.d
|   |-- achar.d
|   |-- adi.d
|   |-- alloca.d
|   |-- array.d

So, I made a script to move the lib files to the new structure. I started to split the linux.mak and I'm planing to create a couple of makefiles (or scripts) to: - change the module declarations. - change the import statments (should work both for the lib and apps) Please stop me if it's not usefull!

I've already done most of it!

good. (But why didn't you ask here? Anybody could to that.) Ant
Oct 31 2003