www.digitalmars.com         C & C++   DMDScript  

D - Single Source Tree

reply Benji Smith <dlanguage xxagg.com> writes:
I have recently finished compiling the zillion or so different software packages
that will be needed to host the new D source-code repository site. Along the
way, I experienced significant enough frustration that I'm proposing that we
change the world. I'll tell you about my frustrating experience first. Then I'll
tell you about what I think we should do about it.

<irrelevant>
I'm hosting the new site on a "virtual dedicated server". There are lots of ways
of doing this (especially in a unix environment (and especially especially in a
linux environment)), but my particular hosting provider does it in such a way
that I get full root access, including the ability to compile and install
software, rwx permissions to every directory in the tree, and the ability to
create arbitrary shell accounts. I can host as many domains as I want on my
server, and I can essentially use it for whatever purposes I like. I get all of
that, plus 3GB of storage space and 25GB of bandwidth each month, for only $15.
The name of the hosting company is http://www.tektonic.net . (The only reason I
mention their name at all is because it's such a good deal, I figure there'll be
someone else in the ng who will be impressed by that price as much as I was. I
don't make any money from tooting their horn. )
</irrelevant>

Anyhow, I've been installing lots of software that will be necessary to get the
repository site up and running. I've had to compile pretty much everything from
source. And I've got some big gripes:

1) You can extract your source archives pretty much anywhere in the directory
tree, as long as you run 'make' and 'make install' from within these
directories. This can lead to source directories all over the place. Some of the
software packages that came preinstalled on my server left their source
directories in some pretty weird places.

2) There is no standard unix location for the installation of binaries, library
files, and include (header) files. Binaries might be installed to '/bin' or
'sbin' or '/usr/bin' or '/usr/sbin' or '/usr/local/bin'. Libraries might be
installed into analagous directories (just substitute 'lib' for 'bin' in any of
these examples) or they might be installed into '/var/lib'. Header files are
even more troublesome to locate. They might be in an analagous directory
(replace 'bin' and 'lib' in any of the preceding examples with 'include'), but
they could also be in a 'src' directory instead of an 'include' directory.
Finally, any software package might choose to install its 'bin', 'lib' and
'include' directories under a single application-specific subdirectory. This
leads to things like '/usr/local/mysql/lib' or '/usr/kerberos/bin'.

When I need to compile new software, and that software needs to link with
existing libraries and header files, it's a huge pain in the ass to track down
the location of the installed files and then set up a CFLAGS environment
variable with a '-I' option pointing to the directory in question.

***************************

I'd like to avoid this type of mayhem in the D community by establishing a
standard location for source code, libraries, and include files.

I don't have much to say about libraries and include files, because I don't have
much experience in the C/C++ world, and I think some of you guys will have more
interesting stuff to say than me about that, but I do have some opinions about a
canonical organization structure for source code. I think that Java got it
right: all source code should be kept in a single code heirarchy, using a deep
directory structure to provide unique canonical names to packages and modules.
All java code written by Sun gets installed into the com > sun directory. Xml
stuff written by the apache group gets installed into the org > apache > xerces
directory. And so on and so on. Using reversed domain names in the
package/module naming convention ensures that my XML api exists in an entirely
different namespace as someone else's XML api.

I know that Burton has imposed this type of canonical package organization to
the dig sources, with module names like 'net.BurtonRadons.dig.main' and I think
we need to move to an organizational structure like that. In fact, I think the
phobos sources should be imported using 'com.digitalmars.phobos.*' just like any
other package. There's no reason they should be special enough to be at the top
of the package hierarchy.

The trouble with this type of organizational structure is that it relies on
everyone having a unique domain name in order to prevent conflicts in canonical
names. And not everybody has a domain name. Especially when the primary members
of the development community are individual developers rather than software
companies.

I have a solution to this problem as well. In a few weeks time, I'll be opening
the gates to the first public source code repository for the D language. All
source code will be available through public cvs access (well, actally it's svn
rather than cvs, but it's the same idea), and I want to organize all of the
projects into a single repository that can be imported using 'com.XXXXX' (where
'XXXXX' will be the domain name of the D repository site, which I'm keeping
under wraps until after I've finished alpha testing). So, when I host a new
project for my XML parsing API, it will be in the 'com.XXXXX.spinnerette'
package, since 'spinnerette' is the name of my XML api.

I think the repository site will also be the best place to host a standard
library, like phobos. So, even though phobos would (at the moment) be imported
using 'com.digitalmars.phobos', I think it should eventually be moved to
'com.XXXXX.phobos', once its development has become a community effort rather
than being primarily under Walter's control.

Do these ideas mesh well with everyone else's conception of how source code
should be organized into hierarchies of packages? Does anyone strongly disagree
here?

We need to hash this out NOW because I need to build the repository structure
within the next two weeks, and whatever gets implemented at that point will be
difficult to reverse.
Sep 10 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
I'm not a unix admin so probably the following
might be wrong, hopefully some one will correct it
if necessary.


 Binaries might be installed to 


'/bin' - system programs 
'sbin' - system programs super user only (root)
/bin and /sbin must be on the boot device

tipicaly /usr is on a separated device that is mounted
after the system boots up.

'/usr/bin' - application programs
'/usr/sbin' - application programs super user only (root)

'/usr/local/bin' - applications programs
'/usr/local/bin' - applications programs super user only (root)

from /usr/ to /usr/local the difference might be what you
want to make public on same kind of remote access
(this one I'm just guessing)

lib, includes and src probably follow the same idea.

There, now you know more about unix then I do.


 All of the projects into a single repository that
 can be imported using 'com.XXXXX'


that's why I wanted to know what was the domain a month ago.

I have one simple problem with that,
my project is not commercial, couldn't we have
com.XXXXX
net.XXXXX
org.XXXXX
..

Ant
Sep 10 2003
parent Benji Smith <dlanguage xxagg.com> writes:
In article <bjovb9$1f22$1 digitaldaemon.com>, Ant says...

 All of the projects into a single repository that
 can be imported using 'com.XXXXX'


that's why I wanted to know what was the domain a month ago.


I would love to tell everyone the domain name right now, but I know that people
would show up to the site and start messing with stuff. I can't allow that until
I've finished with alpha testing. You'll know soon enough.


I have one simple problem with that,
my project is not commercial, couldn't we have
com.XXXXX
net.XXXXX
org.XXXXX


I don't really care whether stuff is commercial or not. The D repository site is
certainly not a for-profit or commercial venture. And yet I'm using a ".com" tld
rather than a ".org". Why? I just like it better, that's why.

Any packages that are hosted strictly using the repository website can use the
package naming convention of 'com.XXXXX.xyz' so that they're gaurunteed a
canonical place to live. However, anyone else who hosts their own code (or
anyone with a domain name, whether they host their code there or not) can use
whatever TLD their domain falls under. So we'll have things like:

com.digitalmars.phobos
org.opend.dli
net.somebodysdsite.wxd
co.uk.xyz.zlib

and so on and so on. My point is that all of these packages should live under a
single parent directory. So, when you checkout a new package from somebody's cvs
repository, you can put it into:

C:\projects\development\d\src_root\org\opend\dli\

Somewhere in your DMD settings, you'd set up your source directory as
"C:\projects\development\d\src_root", and you'll know that your D sources will
always fall somewhere beneath this directory.

--Benji
Sep 10 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Just a few comment on various topics....

Benji Smith wrote:

 
 I have recently finished compiling the zillion or so different software
packages
 that will be needed to host the new D source-code repository site. Along the
 way, I experienced significant enough frustration that I'm proposing that we
 change the world. I'll tell you about my frustrating experience first. Then
I'll
 tell you about what I think we should do about it.


I'm very grateful that you do this.


 Anyhow, I've been installing lots of software that will be necessary to get the
 repository site up and running. I've had to compile pretty much everything from
 source. And I've got some big gripes:
 
 1) You can extract your source archives pretty much anywhere in the directory
 tree, as long as you run 'make' and 'make install' from within these
 directories. This can lead to source directories all over the place. Some of
the
 software packages that came preinstalled on my server left their source
 directories in some pretty weird places.


You can, but you needn't. Typically - I think - a single place like e.g.
   /usr/src/packages/SOURCES
is used.


 2) There is no standard unix location for the installation of binaries, library
 files, and include (header) files. Binaries might be installed to '/bin' or
 'sbin' or '/usr/bin' or '/usr/sbin' or '/usr/local/bin'. Libraries might be
 installed into analagous directories (just substitute 'lib' for 'bin' in any of
 these examples) or they might be installed into '/var/lib'. Header files are
 even more troublesome to locate. They might be in an analagous directory
 (replace 'bin' and 'lib' in any of the preceding examples with 'include'), but
 they could also be in a 'src' directory instead of an 'include' directory.
 Finally, any software package might choose to install its 'bin', 'lib' and
 'include' directories under a single application-specific subdirectory. This
 leads to things like '/usr/local/mysql/lib' or '/usr/kerberos/bin'.
 
 When I need to compile new software, and that software needs to link with
 existing libraries and header files, it's a huge pain in the ass to track down
 the location of the installed files and then set up a CFLAGS environment
 variable with a '-I' option pointing to the directory in question.


It might be easier to have a single -I option and to put a symbolic link
at that place if you choose to have the directory tree elsewhere.

For me /usr/bin feels best.
 

 ***************************
 
 I'd like to avoid this type of mayhem in the D community by establishing a
 standard location for source code, libraries, and include files.


I agree. 
And it should be done the sooner the better for it will break any existing
code. 
Even the small semantic change (in 0.70?) of 'c' was/is a PITA.
 

 I don't have much to say about libraries and include files, because I don't
have
 much experience in the C/C++ world, and I think some of you guys will have more
 interesting stuff to say than me about that, but I do have some opinions about
a
 canonical organization structure for source code. I think that Java got it
 right: all source code should be kept in a single code heirarchy, using a deep
 directory structure to provide unique canonical names to packages and modules.
 All java code written by Sun gets installed into the com > sun directory. Xml
 stuff written by the apache group gets installed into the org > apache > xerces
 directory. And so on and so on. Using reversed domain names in the
 package/module naming convention ensures that my XML api exists in an entirely
 different namespace as someone else's XML api.


It's possible to go this Java path, it's simple and proven. It may be a bit of 
an overkill enforcing long module names and heavy use of aliases.

But Burton seems to have allready walked this way, so it seems fruitless to
discuss this any more.
 

 I know that Burton has imposed this type of canonical package organization to
 the dig sources, with module names like 'net.BurtonRadons.dig.main' and I think
 we need to move to an organizational structure like that. In fact, I think the
 phobos sources should be imported using 'com.digitalmars.phobos.*' just like
any
 other package. There's no reason they should be special enough to be at the top
 of the package hierarchy.


We could use an organized namespace of invented top level domains and
replace
  com.digitalmars.phobos.
by just
  d.


 The trouble with this type of organizational structure is that it relies on
 everyone having a unique domain name in order to prevent conflicts in canonical
 names. And not everybody has a domain name. Especially when the primary members
 of the development community are individual developers rather than software
 companies.


 
Individual programmers could have
  name.TomJones
without even owing such a domain.
 

 I have a solution to this problem as well. In a few weeks time, I'll be opening
 the gates to the first public source code repository for the D language. All
 source code will be available through public cvs access (well, actally it's svn
 rather than cvs, but it's the same idea), and I want to organize all of the
 projects into a single repository that can be imported using 'com.XXXXX' (where
 'XXXXX' will be the domain name of the D repository site, which I'm keeping
 under wraps until after I've finished alpha testing). So, when I host a new
 project for my XML parsing API, it will be in the 'com.XXXXX.spinnerette'
 package, since 'spinnerette' is the name of my XML api.
 
 I think the repository site will also be the best place to host a standard
 library, like phobos. So, even though phobos would (at the moment) be imported
 using 'com.digitalmars.phobos', I think it should eventually be moved to
 'com.XXXXX.phobos', once its development has become a community effort rather
 than being primarily under Walter's control.
 
 Do these ideas mesh well with everyone else's conception of how source code
 should be organized into hierarchies of packages? Does anyone strongly disagree
 here?


As I said, I would prefer a 
  d.   instead of com.XXXXX.phobos or com.digitalmars.phobos
as it wouldn't collide with any existing or future domain.
 

 We need to hash this out NOW because I need to build the repository structure
 within the next two weeks, and whatever gets implemented at that point will be
 difficult to reverse.


I agree. Thank you for your work.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 10 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 I'd like to avoid this type of mayhem in the D community by establishing




a

 standard location for source code, libraries, and include files.


 I agree.
 And it should be done the sooner the better for it will break any existing


code.

 Even the small semantic change (in 0.70?) of 'c' was/is a PITA.


Hear, hear. I am itching to get the win32 registry library written, but this
is one of the things that's tempering my enthusiasm (along with those static
properties, Walter).


 I don't have much to say about libraries and include files, because I




don't have

 much experience in the C/C++ world, and I think some of you guys will




have more

 interesting stuff to say than me about that, but I do have some opinions




about a

 canonical organization structure for source code. I think that Java got




it

 right: all source code should be kept in a single code heirarchy, using




a deep

 directory structure to provide unique canonical names to packages and




modules.

 All java code written by Sun gets installed into the com > sun




directory. Xml

 stuff written by the apache group gets installed into the org > apache >




xerces

 directory. And so on and so on. Using reversed domain names in the
 package/module naming convention ensures that my XML api exists in an




entirely

 different namespace as someone else's XML api.


 It's possible to go this Java path, it's simple and proven. It may be a


bit of

 an overkill enforcing long module names and heavy use of aliases.


It is, but it's unambiguous.


 But Burton seems to have allready walked this way, so it seems fruitless


to

 discuss this any more.


 I know that Burton has imposed this type of canonical package




organization to

 the dig sources, with module names like 'net.BurtonRadons.dig.main' and




I think

 we need to move to an organizational structure like that. In fact, I




think the

 phobos sources should be imported using 'com.digitalmars.phobos.*' just




like any

 other package. There's no reason they should be special enough to be at




the top

 of the package hierarchy.


 We could use an organized namespace of invented top level domains and
 replace
   com.digitalmars.phobos.
 by just
   d.


Yes, I think the standard library should not be at com.digitalmars.phobos.
Presumably we all want this language to succeed and expand. At such time,
would an implementor, e.g. Microsoft, be keen to be writing their modules
within "com.digitalmars.*"? I think not.


 The trouble with this type of organizational structure is that it relies




on

 everyone having a unique domain name in order to prevent conflicts in




canonical

 names. And not everybody has a domain name. Especially when the primary




members

 of the development community are individual developers rather than




software

 companies.


 Individual programmers could have
   name.TomJones
 without even owing such a domain.


Good idea. Would Benji's organisation arbitrate on these, i.e. when we get
multiple people with the same name, or do we assume that there'll be a D
Libraries Group together by then?


 I think the repository site will also be the best place to host a




standard

 library, like phobos. So, even though phobos would (at the moment) be




imported

 using 'com.digitalmars.phobos', I think it should eventually be moved to
 'com.XXXXX.phobos', once its development has become a community effort




rather

 than being primarily under Walter's control.

 Do these ideas mesh well with everyone else's conception of how source




code

 should be organized into hierarchies of packages? Does anyone strongly




disagree

 here?


 As I said, I would prefer a
   d.   instead of com.XXXXX.phobos or com.digitalmars.phobos
 as it wouldn't collide with any existing or future domain.


 We need to hash this out NOW because I need to build the repository




structure

 within the next two weeks, and whatever gets implemented at that point




will be

 difficult to reverse.


 I agree. Thank you for your work.


Yes, and yes. Looking forward to seeing it. :)
Sep 11 2003
parent Helmut Leitner <leitner hls.via.at> writes:
Matthew Wilson wrote:

 

 I'd like to avoid this type of mayhem in the D community by establishing




 a

 standard location for source code, libraries, and include files.


 I agree.
 And it should be done the sooner the better for it will break any existing


 code.

 Even the small semantic change (in 0.70?) of 'c' was/is a PITA.


 
 Hear, hear. I am itching to get the win32 registry library written, but this
 is one of the things that's tempering my enthusiasm (along with those static
 properties, Walter).


Don't want to be misunderstood. I'm very happy with the semantical change of
'c'.

But it broke almost any code and library out there. There are some, that are
not actively maintained. People downloading and testing such code (perhaps 
even in a year) without knowing the internals, might not become happy.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 11 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 ***************************

 I'd like to avoid this type of mayhem in the D community by establishing a
 standard location for source code, libraries, and include files.

 I don't have much to say about libraries and include files, because I


don't have

 much experience in the C/C++ world, and I think some of you guys will have


more

 interesting stuff to say than me about that, but I do have some opinions


about a

 canonical organization structure for source code. I think that Java got it
 right: all source code should be kept in a single code heirarchy, using a


deep

 directory structure to provide unique canonical names to packages and


modules.

 All java code written by Sun gets installed into the com > sun directory.


Xml

 stuff written by the apache group gets installed into the org > apache >


xerces

 directory. And so on and so on. Using reversed domain names in the
 package/module naming convention ensures that my XML api exists in an


entirely

 different namespace as someone else's XML api.


I recall that when I suggested this I was shouted down (boo hoo). However, I
(still) think it's the way to go, so you can count me in.


 I know that Burton has imposed this type of canonical package organization


to

 the dig sources, with module names like 'net.BurtonRadons.dig.main' and I


think

 we need to move to an organizational structure like that. In fact, I think


the

 phobos sources should be imported using 'com.digitalmars.phobos.*' just


like any

 other package. There's no reason they should be special enough to be at


the top

 of the package hierarchy.


All my stuff is currently synsoft.*, but I think I'll probably move it to
org.synsoft.* if we see a groundswell of support.


 The trouble with this type of organizational structure is that it relies


on

 everyone having a unique domain name in order to prevent conflicts in


canonical

 names. And not everybody has a domain name. Especially when the primary


members

 of the development community are individual developers rather than


software

 companies.

 I have a solution to this problem as well. In a few weeks time, I'll be


opening

 the gates to the first public source code repository for the D language.


All

 source code will be available through public cvs access (well, actally


it's svn

 rather than cvs, but it's the same idea), and I want to organize all of


the

 projects into a single repository that can be imported using 'com.XXXXX'


(where

 'XXXXX' will be the domain name of the D repository site, which I'm


keeping

 under wraps until after I've finished alpha testing). So, when I host a


new

 project for my XML parsing API, it will be in the 'com.XXXXX.spinnerette'
 package, since 'spinnerette' is the name of my XML api.


I like the fact that you're willing to supply them, but ...


 I think the repository site will also be the best place to host a standard
 library, like phobos. So, even though phobos would (at the moment) be


imported

 using 'com.digitalmars.phobos', I think it should eventually be moved to
 'com.XXXXX.phobos', once its development has become a community effort


rather

 than being primarily under Walter's control.


... I strongly disagree with this. If we like

  org.blah.lib-main.lib-individual.*
  com.digitalmars.phobos.

isn't putting everything into

  com.XXXXX.*

utterly pointless, since everything will just have com.XXXXX in front of it.

The second objection is people will simply not take to being
forced/coerced/obliged to go into "the one true way".

The third reason is that I can't see Walter going with it in a month of
Sundays.


For my part I think it's useful and important to:

 (i) Have a consistent, coherent, predictable and inclusive structure.
 (ii) Have a standard library (owned by Digital Mars until the language gets
all ISO'd) that has a distinguisable identity.

The com.domain.lib.sub-lib.* format is very good for this, it's just not the
whole answer. I think that Phobos should be under

  D

as in

  D.rtl.stdio
  D.lang.except

Note that this distingushes between language and standard rtl features.

(I personally don't want Phobos as part of the package names, though I do
want to keep it as the (un)official name of the rtl distribution, but I'm
not sure it's up to me. ;)


 Do these ideas mesh well with everyone else's conception of how source


code

 should be organized into hierarchies of packages? Does anyone strongly


disagree

 here?


Yes and no


 We need to hash this out NOW because I need to build the repository


structure

 within the next two weeks, and whatever gets implemented at that point


will be

 difficult to reverse.
Sep 11 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjp6oc$1pie$1 digitaldaemon.com...

 [...] If we like

   org.blah.lib-main.lib-individual.*
   com.digitalmars.phobos.

 isn't putting everything into

   com.XXXXX.*

 utterly pointless, since everything will just have com.XXXXX in front of


it.

That could in fact make less people willing to host their projects on the
repository site.There are companies which release open source code; I don't
think they'd go with anything else than com.companyname for their libraries.
They spend money on it, leave them the glory at least. :)


 The third reason is that I can't see Walter going with it in a month of
 Sundays.


The worst thing about Walter, IMHO, is that he doesn't have a copy
constructor so we can clone him. :-)


 The com.domain.lib.sub-lib.* format is very good for this, it's just not


the

 whole answer. I think that Phobos should be under

   D

 as in

   D.rtl.stdio
   D.lang.except

 Note that this distingushes between language and standard rtl features.


Agreed completely. Let Phobos remain as a codename, but the D RTL is part of
D, just as Windows is not Whistler, OpenDOS is OpenDOS and not any of its
fancy release codenames, etc.

Ric
Sep 11 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
In article <bjpdn4$241a$2 digitaldaemon.com>, Riccardo De Agostini says...

"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjp6oc$1pie$1 digitaldaemon.com...

 [...] If we like

   org.blah.lib-main.lib-individual.*
   com.digitalmars.phobos.

 isn't putting everything into

   com.XXXXX.*

 utterly pointless, since everything will just have com.XXXXX in front of


it.

That could in fact make less people willing to host their projects on the
repository site.There are companies which release open source code; I don't
think they'd go with anything else than com.companyname for their libraries.
They spend money on it, leave them the glory at least. :)


The point is that library authors *could* use the com.XXXXX prefix for their
libraries, guarunteeing them a unique canonical name. However, there's no need
to impose that type of naming convention on them if they already have a domain
name of their own. I agree that it would be pointless to have everything reside
under the com.XXXXX structure. I'm just saying that I'll make sure those project
names are unique so that the package names are also unique.

I also don't think there's anything special about internet domain names, except
that they're canonical, by definition. I think that's the only reason that
they're used as package names in Java (AFAIK, there is no auto-downloading
feature for classes in Java).

If we don't use domain names as package name prefixes, how do you suggest we
gauruntee unique package names? I'd hate to have to download a package from
'name.johnsmith.*' and not know that the "johnsmith" name is gaurunteed to be
unique. Of course, I don't really care about the domain names themselves, so if
you can think of another system that gauruntees unique canonical names, I'd like
to hear it. And I'm not crazy about the idea of using my repository site as a
registrar of package names. But you might be able to convince me. Maybe.

--Benji Smith
Sep 11 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Benji Smith wrote:

 If we don't use domain names as package name prefixes, how do you suggest we
 gauruntee unique package names? I'd hate to have to download a package from
 'name.johnsmith.*' and not know that the "johnsmith" name is gaurunteed to be
 unique. 


While I see your point, I can't agree. The chance for such a collision is small
(always in mind that the typical coding will be done using correct domain
names).

Anyway your system will have to accept the given domain names without a chance
to check them. So I suppose anyone could check in a "com.acorp.module" without
being the owner of the domain "acorp.com" and you wouldn't even notice it.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 11 2003
parent Benji Smith <dlanguage xxagg.com> writes:
In article <3F608254.36C58B20 hls.via.at>, Helmut Leitner says...

Anyway your system will have to accept the given domain names without a chance
to check them. So I suppose anyone could check in a "com.acorp.module" without
being the owner of the domain "acorp.com" and you wouldn't even notice it.


Yes. For example, it seems as though Burton Radons, who is currently using the
prefix 'net.BurtonRadons' for his dig packages, doesn't actually own the domain
name 'burtonradons.net'. I think that's a mistake on his part. I think that if
he's writing code using that prefix, it implies that you can visit
www.burtonradons.net for more information about the packages. In this case,
that's not true.

So the domain name convention provide any mechanism for guarunteeing that people
only write code for their own domains. In fact, I could write java code and call
my packages 'com.sun.java.blingblang'. If I do so, I have to hope that Sun will
never release a package called 'blingblang'. If they do, I'm the one who will
have to change my package name, since they're the domain owners.

I know that namespace conlicts will be rare, no matter what naming convention we
use, but at some point, there will be a few conflicts (if we get to the point
where there is an active library-development community (and we're all hoping for
that)). Using a domain-name-based package-naming convention, we'll have some way
of figure out how to resolve those conflicts. But maybe there's a better
convention we can use. If you have any ideas, I want to hear them.

--Benji
Sep 11 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Benji Smith" <dlanguage xxagg.com> ha scritto nel messaggio
news:bjosk1$1aut$1 digitaldaemon.com...

 I have recently finished compiling the zillion or so different software


packages

 that will be needed to host the new D source-code repository site.


Oh, BTW... I had missed your first posts about the repository site. Although
late, please accept my thanks and congratulations.


 I don't have much to say about libraries and include files, because I


don't have

 much experience in the C/C++ world, and I think some of you guys will have


more

 interesting stuff to say than me about that, but I do have some opinions


about a

 canonical organization structure for source code. I think that Java got it
 right: all source code should be kept in a single code heirarchy, using a


deep

 directory structure to provide unique canonical names to packages and


modules.

If you're in a hurry, skip next paragraph: it's just to say that I agree. :)

I'm not a Java programmer, but I've seen some Java code and sure, it has the
best code organization I've ever seen. And if setting up for compilation
under Linux is a pain because of too many "standard" paths, how about DOS
and Windows, that have none?! Every time I have to set up a new development
machine, or make some modifications to old code and thus install those four
or five libraries I haven't been using for a couple of years, I get asked
why a modification so trivial took me a whole week... but it usually took 4
days just to have it recompile as-is!
And don't even mention "smart" component-based IDEs! Yes, for the first time
ever, this ng is seeing me complaining about Delphi! :)


 The trouble with this type of organizational structure is that it relies


on

 everyone having a unique domain name in order to prevent conflicts in


canonical

 names. And not everybody has a domain name. Especially when the primary


members

 of the development community are individual developers rather than


software

 companies.


I can't believe that! What sense does it make to constrain the source tree
structure to actual Internet registered domains? It may be right for Java,
so the VM may download at runtime a class used by an applet and know exactly
where to save it for later retrieval, but maybe it could be not so strict a
requirement for D.


 I have a solution to this problem as well. [...] So, when I host a new
 project for my XML parsing API, it will be in the 'com.XXXXX.spinnerette'
 package, since 'spinnerette' is the name of my XML api.


I'm with Ant here: org.XXXXX would be better. But I'm not going to start a
holy war on that: there are too many more important things that are to be
dealt with, one of the most important ones being having the repository site
up and running, so it could even be biz.XXXXX for what it's worth.

Thanks again for your precious work
Ric
Sep 11 2003
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
I don't think i like lengthy names, including arbitrary domains. I would 
propose that:

  - There is only one repository site.
  - Project names *are* namespace names. No "com.blahblah" in front;
  - To avoid collisions, "d" and "c" should be pre-registered, and all 
commercial companies developing their code, should register their 
projects or namespaces on the repository site. They could use webspace 
as redirection, as well as file download facility, but they need not use 
svn.
  - "d" stands for standard libraries - currently Phobos.

I can't recall any name collision when using Delphi, even though it uses 
next to no namespace protection.

-eye


PS. Ricardo: you do not need to register components with the IDE just to 
make Delphi compile some project which uses them. :) Just show it the 
path and it shall figure out. :) Much less pain than i'm having with 
C++, which relies on the actual file positions, almost manual linking, 
and so on...
Sep 11 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Ilya Minkov" <minkov cs.tum.edu> ha scritto nel messaggio
news:bjprc8$2lk3$1 digitaldaemon.com...

   - There is only one repository site.


...which, at this point, would also serve as namespace registrar, right?
Benji said he doesn't love the idea much, but it makes a lot of sense.


   - Project names *are* namespace names. No "com.blahblah" in front;


I'd leave developers with the possibility of prepending the developer name,
as in "burtonradons.yetanotherlib" instead of just "yetanotherlib" if Burton
so wishes. I'm not with the Internet domain idea, definitely.
Of course I'm not ever releasing anything called "riccardodeagostini.mylib",
or rewriting the library could take less time than typing the imports... :)


 I can't recall any name collision when using Delphi, even though it uses
 next to no namespace protection.


Me neither. Though people like TurboPower have always used two-letter
prefixes on all their units' names...


 PS. Ricardo: you do not need to register components with the IDE just to
 make Delphi compile some project which uses them. :) Just show it the
 path and it shall figure out. :) Much less pain than i'm having with
 C++, which relies on the actual file positions, almost manual linking,
 and so on...


Granted, Delphi is not the worst case. But I don't even want to show it the
path, call me lazy! :) I want a single setting (or environment variable) a
la CLASSPATH. I want to be able to just copy the entire "classpath" tree to
my new development box and have it working at once. I want to be able to use
a classpath (in lack, for now, of a better name) on a network share. OK,
maybe I want too much, but I tried... :)

Ric
Sep 11 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
Riccardo De Agostini wrote:

  - There is only one repository site.


 
 ...which, at this point, would also serve as namespace registrar, right?
 Benji said he doesn't love the idea much, but it makes a lot of sense.


Exactly!

Now i have gotten second thoughts. The official name registration 
facility may be at Walter's or Jan's site - it should be free and 
voluntary, but everyone should do it when releasing an open-source 
library to the world...

The world need not be limited to one repository - but the repositories 
would need to co-operate on giving away project names.

It just seems to me that if there is a central repository, there isn't 
much sense to make its project fall into such a deep namespace... They 
can be top-level if the obvious names can be reserved.


  - Project names *are* namespace names. No "com.blahblah" in front;


 
 I'd leave developers with the possibility of prepending the developer name,
 as in "burtonradons.yetanotherlib" instead of just "yetanotherlib" if Burton
 so wishes. I'm not with the Internet domain idea, definitely.


yeah, if he has registered a project of his name. :)

But well, the idea with domains is not bad for people who do not want to
be dependant on the central registration service... but want to have
net, com, org, or whatever in the beginning of their unit names. This 
way should be open to them, and having a top-level domain name in the 
beginning would clearly disambiguate them from anything else.

This all leads to a possible necessity to make it possible to register
sub-projects... This is probably not important at first, but later it
could be good. The projects would get a dot in their name and would be
acessible as

subproject.project.XXXXX.com
www.XXXXX.com/projects/project.subproject

but for the first the members should simply arrange directories in their
webspace to match sub-project names.

www.XXXXX.com/projects/project/subproject
project.XXXXX.com/subproject


 Me neither. Though people like TurboPower have always used two-letter
 prefixes on all their units' names...


Ah, that's the reason. :) Besides, important libs were well known and
noone would dare to invent a colliding name. :)


 Granted, Delphi is not the worst case. But I don't even want to show it the
 path, call me lazy! :) I want a single setting (or environment variable) a
 la CLASSPATH.


The only thing that lacked there was a recursive search of
sub-directories which would eliminate the problem completely. :) Plus a
possibility to exclude a certain directory from search by putting a flag
file into it. :)

There is a deep ocean to similar things. Like, with most windows
proggies - you move it and it breaks. And later it should not be able to
uninstall itself. Thus reorganising software is bound to go through pain
of uninstall- reinstall- reconfigure... Unlike on a mac - move and it
picks on. Even on another computer. That's how everything should work -
including compilers. :)))))) This imposes another problem within
multi-user environmants but i have figured out a solution as well ;) ...
Gotta tell it the Yellow Tab (BeOS/Zeta) crew before it's too late. :)

-eye
Sep 11 2003
prev sibling next sibling parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bjosk1$1aut$1 digitaldaemon.com...

 I have recently finished compiling the zillion or so different software


packages

 that will be needed to host the new D source-code repository site. Along


the

Incredible work Benji. I know I'll be using your services a lot. I read this
newsgroup almost dayly but don't get into the discussions too often. But
this kind of donation to the comunity surely deserves congratulations from
everyone here.




 I'd like to avoid this type of mayhem in the D community by establishing a
 standard location for source code, libraries, and include files.


A standard location for D source code it's a really good idea. Java's naming
convention for packages it's a little clumsy but works pretty well. As
Ricardo said, there's no need to add com. or net. to module names in D and
probably add a lot of collisions with variable names:


import com.digitalmars.win32;

void main()
{
    ComObject com = new ComObject();
    com.AddRef();
}

test.d(7): undefined identifier module com.AddRef


I think module names should be MixedCase and prepending the name of the
company or organization that is mantaining it, except of course for the
standard library wich should be D:

import D;    // implicitly imported.
import D.Win32;
import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
import Microsoft.ADO;
import Eclipse.SWT.Widgets;

And for independent developers we should decide on a standard module that
will be open for them:

import Contrib.BurtonRadons.DIG;
import Contrib.JulioCesarCarrascal.SomeLib;


It can be "Contrib", "Personal", "Name", etc. I don't mind as long as it is
reserved for that use.
Sep 11 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
I totally aggree with this option, I dont like the com / org prefix, but a
company/ organization name prefix seems to work beautifully.  I also vote
for the Contrib, though JulioCesarCarrascal is a lot of typing and easy to
get wrong!

Charles


"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bjq5f6$2fd$1 digitaldaemon.com...

 "Benji Smith" <dlanguage xxagg.com> wrote in message
 news:bjosk1$1aut$1 digitaldaemon.com...

 I have recently finished compiling the zillion or so different software


 packages

 that will be needed to host the new D source-code repository site. Along


 the

 Incredible work Benji. I know I'll be using your services a lot. I read


this

 newsgroup almost dayly but don't get into the discussions too often. But
 this kind of donation to the comunity surely deserves congratulations from
 everyone here.




 I'd like to avoid this type of mayhem in the D community by establishing




a

 standard location for source code, libraries, and include files.


 A standard location for D source code it's a really good idea. Java's


naming

 convention for packages it's a little clumsy but works pretty well. As
 Ricardo said, there's no need to add com. or net. to module names in D and
 probably add a lot of collisions with variable names:


 import com.digitalmars.win32;

 void main()
 {
     ComObject com = new ComObject();
     com.AddRef();
 }

 test.d(7): undefined identifier module com.AddRef


 I think module names should be MixedCase and prepending the name of the
 company or organization that is mantaining it, except of course for the
 standard library wich should be D:

 import D;    // implicitly imported.
 import D.Win32;
 import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
 import Microsoft.ADO;
 import Eclipse.SWT.Widgets;

 And for independent developers we should decide on a standard module that
 will be open for them:

 import Contrib.BurtonRadons.DIG;
 import Contrib.JulioCesarCarrascal.SomeLib;


 It can be "Contrib", "Personal", "Name", etc. I don't mind as long as it


is

 reserved for that use.
Sep 11 2003
prev sibling next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> ha scritto nel
messaggio news:bjq5f6$2fd$1 digitaldaemon.com...

 I think module names should be MixedCase and prepending the name of the
 company or organization that is mantaining it, except of course for the
 standard library wich should be D:

 import D;    // implicitly imported.
 import D.Win32;
 import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
 import Microsoft.ADO;
 import Eclipse.SWT.Widgets;


I'm with you on the name hierarchy, but I'd stick to lower case only.


 And for independent developers we should decide on a standard module that
 will be open for them:

 import Contrib.BurtonRadons.DIG;
 import Contrib.JulioCesarCarrascal.SomeLib;


Why not let Burton, or yourself, have his own top level namespace? Hasn't an
independent developer the same dignity as a corporation?

Ric
Sep 12 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Riccardo De Agostini wrote:

 
 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> ha scritto nel
 messaggio news:bjq5f6$2fd$1 digitaldaemon.com...

 I think module names should be MixedCase and prepending the name of the
 company or organization that is mantaining it, except of course for the
 standard library wich should be D:

 import D;    // implicitly imported.
 import D.Win32;
 import DigitalMars.ReflectionExtension;    // Tips, tips, tips ...
 import Microsoft.ADO;
 import Eclipse.SWT.Widgets;


 
 I'm with you on the name hierarchy, but I'd stick to lower case only.
 

 And for independent developers we should decide on a standard module that
 will be open for them:

 import Contrib.BurtonRadons.DIG;
 import Contrib.JulioCesarCarrascal.SomeLib;


 
 Why not let Burton, or yourself, have his own top level namespace? Hasn't an
 independent developer the same dignity as a corporation?


It wouldn't be funny to have a top level domain directrory with hundreds 
of entries, somewhere in between, hard to find, "d", "org" and "com" where 
the music really plays.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 12 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Helmut Leitner wrote:


 It wouldn't be funny to have a top level domain directrory with hundreds 
 of entries, somewhere in between, hard to find, "d", "org" and "com" where 
 the music really plays.


I frankly can't see what the problem would be. Would you please explain 
what you mean?

-eye
Sep 12 2003
parent Helmut Leitner <helmut.leitner chello.at> writes:
Ilya Minkov wrote:

 
 Helmut Leitner wrote:
 

 It wouldn't be funny to have a top level domain directrory with hundreds
 of entries, somewhere in between, hard to find, "d", "org" and "com" where
 the music really plays.


 
 I frankly can't see what the problem would be. Would you please explain
 what you mean?


There is no problem, its just aestetical. A top level like

  ROOT/c
      /com
      /d
      /name
      /net
      /org

would just look better to me than having hundreds of entries at this level.

It would also be easier to select a semantical part of it like e. g. 

      /c
      /d
      /org

for updating. 

And I think that the Java-like domain type organization is basically a good
way to go, just not in the strict sense that forces phobos into

      /com/digitalmars/phobos

Just my $0.02.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 12 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bjq5f6$2fd$1 digitaldaemon.com...
| ...
| And for independent developers we should decide on a standard module that
| will be open for them:
|
| import Contrib.BurtonRadons.DIG;
| import Contrib.JulioCesarCarrascal.SomeLib;
|

As Charles said, writing a whole name could be very prone to errors (just a
sample: this is copied and pasted because I still don't know how to write
it: Achilleas Margaritis... well, we live in a world with a lot of
diversity).

However I really like the contrib part, for what my vote counts.

But I don't think we should use people's names. I don't see the need. Sure,
it's good to give credit to the creator, but I think it could envolve too
much complexity. Maybe it could be better if somewhere was maintained a
central library names repository (was it already proposed? I think so). I'm
mixing things, but think about this:

import contrib.DanielYokomiso.deimos;
import contrib.[SorryIForgotThePerson].deimos;

The first one is a template library. The second one is to convert .h files
to d modules. Now, someone new comes and sees that, he won't know what to do
because both things have the same name (ok, the second one isn't a library,
but you get the point). The point is to avoid name duplication. So Benji
could do that at first (register names), and later someone else could (I
dunno... maybe there'll be an International D Organization where those
things could be ruled).

[Sometimes I tend to talk too much and not say much, mix ideas... But that's
pretty much what's in my mind about this]

—————————————————————————
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 2003-09-01
Sep 12 2003
parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
Carlos Santander wrote:

 But I don't think we should use people's names. I don't see the need.


Sure,

 it's good to give credit to the creator, but I think it could envolve too
 much complexity. Maybe it could be better if somewhere was maintained a


Yes, names from other countries can be difficult to write but if if we drop
developer name's there's a problem that I'll try to explain better (I'm
wrestling with my poor english).



 import contrib.DanielYokomiso.deimos;
 import contrib.[SorryIForgotThePerson].deimos;

 The first one is a template library. The second one is to convert .h files
 to d modules. Now, someone new comes and sees that, he won't know what to


do

What if some of us wanted to re-implement the standard XML library? We could
easly choose one of the following:

import D.XML;
import Contrib.JulioCesarCarrascal.XML;
import Contrib.DanielYokomiso.XML;
import Contrib.CarlosSantander.XML;

And, as long each one implemented the same public interface, the code using
the library will work fine. I'm bringing this up is because the first
implementation almost always isn't the fastest or the smallest and people
will prefer Daniel's XML library.



 dunno... maybe there'll be an International D Organization where those
 things could be ruled).


Maybe an "International D Organization" it's a political overkill for an
issue that could be solved with just a good naming convention for module
names.

Also, I vote for mixed-case names so we can avoid name collisions with
variables. Modules look a lot more like classes than variables. That's why I
think lower-case names for modules is inconsistent.




 [Sometimes I tend to talk too much and not say much, mix ideas... But


that's

 pretty much what's in my mind about this]


Me too. I'm thinking to go back to the domain name thing and drop the whole
issue  :)
Sep 13 2003
next sibling parent John Boucher <John_member pathlink.com> writes:
In article <bjvc01$19bv$2 digitaldaemon.com>, Julio César Carrascal Urquijo
says...

 dunno... maybe there'll be an International D Organization where those
 things could be ruled).


Maybe an "International D Organization" it's a political overkill for an
issue that could be solved with just a good naming convention for module
names.


Howsabout "D Organization of Heuristics" AKA "D'OH!"


Also, I vote for mixed-case names so we can avoid name collisions with
variables. Modules look a lot more like classes than variables. That's why I
think lower-case names for modules is inconsistent.


As an unrepentant OpenVMS guy I don't like case sensitivity in file systems.
What if a D compiler is ever ported to OpenVMS? (As if!)

John Boucher
The King had Humpty pushed.
Sep 13 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> escreveu na mensagem
news:bjvc01$19bv$2 digitaldaemon.com...

 Carlos Santander wrote:


[snip]


 import contrib.DanielYokomiso.deimos;
 import contrib.[SorryIForgotThePerson].deimos;





[snip]


 import D.XML;
 import Contrib.JulioCesarCarrascal.XML;
 import Contrib.DanielYokomiso.XML;
 import Contrib.CarlosSantander.XML;


Am I becoming famous? Must be, now I'm an code example ;)


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/9/2003
Sep 13 2003
prev sibling next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Benji Smith" <dlanguage xxagg.com> escreveu na mensagem
news:bjosk1$1aut$1 digitaldaemon.com...

[snip]

Using a single source tree has a couple of problems.

First it won't help with different versions of source code, so if I have to
use version 0.3.5 of dig with dcc 1.2, but dTree 1.0.2 uses dig 0.2.4 I'll
have to place both versions somewhere in the tree. I had this problem in
Java once (particularly nasty when you consider different versions of JDK
break different libraries in different ways). Also installing newer versions
will be more fun: instead of just installing a new version under a dlib1.0.3
folder he'll have to remember which were the old modules and delete them
before, in the case the project splitted a single module in two (somewhat
common).

Second it's hard to keep track of dependencies. If we have the Java model
and look at Apache we'll see lots of code under the org.apache tree, but
some pieces are from xml (e.g. xerces and xalan) other from jakarta (e.g.
bcel, tomcat) all from different projects with different maintainers. Also
they keep different branches sometimes (Xerces has two active releases
IIRC). It's very difficult to keep track of everything, from maintainers
rights to versioning if everything falls under the same tree inside the cvs,
so they keep different projects inside the cvs and everything is fine. But
if the user has to maintain everything in a single source he won't be able
to keep track over things using cvs (i.e. the tree org.apache will be shared
in his box but separated in the server), so he'll probably maintain things
that he update from cvs outside the released trees.

I like the idea of a single source tree, but it doesn't work with the
filesystems we have. If we had a filesystem aware of library versions and
able to distinguish two projects that live under the same tree it would be
easier.

<wishful-thinking>
Someone ;) mentioned a virtual filesystem project earlier for D, perhaps we
could modify this idea and come with a D library manager (DLM): new
libraries are downloaded in compressed form (using a standard D installer
creating an executable binary) and installed in the DLM location. During the
installation the DLM becomes aware of the library version and dependencies,
so it'll be able to keep it in a separated fisical location, but logically
connected to the other modules (including versioning conflicts, etc.).
During compilation the DLM can offer the real path to the compiler, so we
just can "dlmc <my_project>" and it'll call the registered compiler with the
appropriate paths. It would handle dll versioning too and clean our houses
;)
</wishful-thinking>

BTW, the repository site idea is very good, but I don't think every project
must be named after a domain name, specially the domain name of the site. D
standard libraries should be under "d" and specific projects should be under
their own module names (e.g. dtlsoft). IMHO using domain names is wrong
because they put all "org.*" under the same logical tree even if they have
no connection.

    Best regards,
    Daniel Yokomiso.

"The consumer is not an idiot, she is your wife."
 - David Ogilvy, founder of Ogilvy & Mather


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003
Sep 11 2003
next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> ha scritto nel messaggio
news:bjr3nu$1cjr$1 digitaldaemon.com...

 First it won't help with different versions of source code, so if I have


to

 use version 0.3.5 of dig with dcc 1.2, but dTree 1.0.2 uses dig 0.2.4 I'll
 have to place both versions somewhere in the tree. I had this problem in
 Java once (particularly nasty when you consider different versions of JDK
 break different libraries in different ways). Also installing newer


versions

 will be more fun: instead of just installing a new version under a


dlib1.0.3

 folder he'll have to remember which were the old modules and delete them
 before, in the case the project splitted a single module in two (somewhat
 common).


<daydreaming>

-----<in myprog.d>-----
import stlsoft.vector version 2.0;

-----<in vector.d>------

version 2.2 compatible 2.0;

-----<in other words...>-----

How about automatic version checking by the compiler?

<daydreaming>

(This time Walter is going to ban me from the ng :-) )

Ric
Sep 12 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bjs2et$2o89$1 digitaldaemon.com>, Riccardo De Agostini wrote:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> ha scritto nel messaggio
 news:bjr3nu$1cjr$1 digitaldaemon.com...

 First it won't help with different versions of source code, so if I have


 to

 use version 0.3.5 of dig with dcc 1.2, but dTree 1.0.2 uses dig 0.2.4 I'll
 have to place both versions somewhere in the tree. I had this problem in
 Java once (particularly nasty when you consider different versions of JDK
 break different libraries in different ways). Also installing newer


 versions

 will be more fun: instead of just installing a new version under a


 dlib1.0.3

 folder he'll have to remember which were the old modules and delete them
 before, in the case the project splitted a single module in two (somewhat
 common).


 
<daydreaming>
 
 -----<in myprog.d>-----
 import stlsoft.vector version 2.0;
 
 -----<in vector.d>------
 
 version 2.2 compatible 2.0;
 
 -----<in other words...>-----
 
 How about automatic version checking by the compiler?
 
<daydreaming>
 
 (This time Walter is going to ban me from the ng :-) )


I hope not, but the issue is not very simple.

Having two different versions in the source tree (and being able to pick
one in an "import" sentence) would be a rather useful feature. Look at
the difficulty that one has to go through to compile a project that has
15 libraries it depends on. If all the libraries are under development
and break all the time, hell breaks loose. (Ever tried to compile GNOME
on Linux?)

The fundamental thing is:

I want to be confident that when upgrading SomeProject from 1.0 to 1.1
the former version won't be overwritten and all software that depends on
version 1.0 can be still compiled and used as if nothing had happened.

You might want also to say something like

import stlsoft.vector version >=2.0;

or

import dot.com.boom.bang.xml version 1.0 .. 1.2;

(now would that mean 1.0 <= version < 1.2 or 1.0 <= version <= 1.2...)

More things to think about... How do you compare version numbers, for
example? There are plenty of different version number schemes, starting
from simple x.y.z where x, y and z are numbers, to something like
1.0445j and 2.0-pre4. And you might have branches that are indicated in
the version number (Linux kernel has branched versions such as
2.4.21-pre5-ac3, but that kind of versioning might be out of scale
here)

-Antti
Sep 14 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> ha scritto nel messaggio
news:slrnbm8n8o.rsn.jsykari pulu.hut.fi...

 More things to think about... How do you compare version numbers, for
 example? There are plenty of different version number schemes, starting
 from simple x.y.z where x, y and z are numbers, to something like
 1.0445j and 2.0-pre4. And you might have branches that are indicated in
 the version number (Linux kernel has branched versions such as
 2.4.21-pre5-ac3, but that kind of versioning might be out of scale
 here)


Clearly (though not so clearly from my previous post) automatic version
checking would imply a standard and well-defined versioning scheme to which
all libraries should adhere. This is probably going to be an all too good
topic for holy wars. I myself have been using different versioning schemes
for different projects and all of them made sense in their own context.

Just to start with something, how about the classic
<version>.<subversion>.<release>?

Ric
Sep 15 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Daniel Yokomiso wrote:

 <wishful-thinking>
 Someone ;) mentioned a virtual filesystem project earlier for D, perhaps we
 could modify this idea and come with a D library manager (DLM): new
 libraries are downloaded in compressed form (using a standard D installer
 creating an executable binary) and installed in the DLM location. During the
 installation the DLM becomes aware of the library version and dependencies,
 so it'll be able to keep it in a separated fisical location, but logically
 connected to the other modules (including versioning conflicts, etc.).
 During compilation the DLM can offer the real path to the compiler, so we
 just can "dlmc <my_project>" and it'll call the registered compiler with the
 appropriate paths. It would handle dll versioning too and clean our houses
 ;)
 </wishful-thinking>


Operating systems should allow to make directories mirror other 
directories. When you look into this directory(1), you see files which 
are actually in another directory(2), plus the files in (1). If the file 
with the same name exists in both, you see the one in (1). However, 
whenever you try to write or modify files through (1) - the changes 
should be written in (1) even if the original file was in (2).

This simple magic allows to write programs which would store their 
configuration in their directory, that is the way single-user systems 
work. In the multi-user environment, an administrator would install 
bunches of software on some common read-only storage. If a sertain user 
wants to use some piece of software, he simply creates a directory for 
it in his space - wherever he wants - and lets it mirror the actual 
location, which may be read-only... and it works rightaway.

I don't know whether any OS already implements such a thing or not, but 
i believe it would be of a lot of help in all cases, where 
configurations need to be slightly different and directory structures 
clean... There must also be some way to hide files in a mirror...

Don't know whether this particular idea of mine expands to library 
version control, and it doefinately doesn't expand to some operating 
systems... So your idea is good anyway.

Lunatic mentioned a virual filesystem which would work on associated 
words, instead of directores. But it wasn't related to D.

-eye
Sep 12 2003
parent reply John Boucher <John_member pathlink.com> writes:
This sounds like what I do with search lists on OpenVMS...
One can define a logical name that actually points to a list of directories.

Something like:
define appdir "appdisk:[app] , usrdisk:[me.app]"
(I've forgotten the exact syntax in the year-and-a-half I've been away from
OpenVMS.)

Now I can use:
dir appdir
and see both directories.

I can also:
set default appdir
("set default" is "change directory")

And I can say that my config file (or data or whatever) is appdir:app.cfg

Now, if I'm a new user with no personal config file, I get the shared one from
the appdisk, if I already have a config file it will be found in my directory,
and when I save the file it gets saved in my directory for future use.

I used this quite a bit when programming on OpenVMS. For each project I had a
WORK and a CLEAN directory with a search list containing them (in that order). I
would fetch code from CMS (CVS) into the CLEAN directory. Then I could look at
the file and if I modified it it would be saved into the WORK directory. Then I
could send only the files in WORK back to CMS.

This sort of thing also simplifies builds, you don't need to have everything in
one physical directory, you don't need to add a whole ton of directories to your
include and library switches. And you can have any intermediate files be created
away from the source code.

OpenVMS' logicals are perhaps the most powerful feature of the OS and yet no
other OS uses them? They're way better than logical link files.

I'll also add that OpenVMS has the ability to have multiple names for a
directory or file (which is dangerous and seldom used).

In article <bjt4bc$14ig$1 digitaldaemon.com>, Ilya Minkov says...

Daniel Yokomiso wrote:

 <wishful-thinking>
 Someone ;) mentioned a virtual filesystem project earlier for D, perhaps we
 could modify this idea and come with a D library manager (DLM): new
 libraries are downloaded in compressed form (using a standard D installer
 creating an executable binary) and installed in the DLM location. During the
 installation the DLM becomes aware of the library version and dependencies,
 so it'll be able to keep it in a separated fisical location, but logically
 connected to the other modules (including versioning conflicts, etc.).
 During compilation the DLM can offer the real path to the compiler, so we
 just can "dlmc <my_project>" and it'll call the registered compiler with the
 appropriate paths. It would handle dll versioning too and clean our houses
 ;)
 </wishful-thinking>


Operating systems should allow to make directories mirror other 
directories. When you look into this directory(1), you see files which 
are actually in another directory(2), plus the files in (1). If the file 
with the same name exists in both, you see the one in (1). However, 
whenever you try to write or modify files through (1) - the changes 
should be written in (1) even if the original file was in (2).

This simple magic allows to write programs which would store their 
configuration in their directory, that is the way single-user systems 
work. In the multi-user environment, an administrator would install 
bunches of software on some common read-only storage. If a sertain user 
wants to use some piece of software, he simply creates a directory for 
it in his space - wherever he wants - and lets it mirror the actual 
location, which may be read-only... and it works rightaway.

I don't know whether any OS already implements such a thing or not, but 
i believe it would be of a lot of help in all cases, where 
configurations need to be slightly different and directory structures 
clean... There must also be some way to hide files in a mirror...

Don't know whether this particular idea of mine expands to library 
version control, and it doefinately doesn't expand to some operating 
systems... So your idea is good anyway.

Lunatic mentioned a virual filesystem which would work on associated 
words, instead of directores. But it wasn't related to D.

-eye


John Boucher
The King had Humpty pushed.
Sep 12 2003
parent Derek Parnell <Derek.Parnell No.Spam> writes:
On Fri, 12 Sep 2003 21:03:44 +0000 (UTC) (09/13/03 07:03:44)
, John Boucher <John_member pathlink.com> wrote:

[snip]

 OpenVMS' logicals are perhaps the most powerful feature of the OS and 
 yet no
 other OS uses them? They're way better than logical link files.

 I'll also add that OpenVMS has the ability to have multiple names for a
 directory or file (which is dangerous and seldom used).


And automatic file versioning!


-- 
Derek
Sep 14 2003
prev sibling parent J Anderson <anderson badmama.com.au.REMOVE> writes:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>

My .02c<br>
<blockquote type="cite" cite="midbjosk1$1aut$1 digitaldaemon.com">
  <pre wrap="">I think the repository site will also be the best place to host
a standard
library, like phobos. So, even though phobos would (at the moment) be imported
using 'com.digitalmars.phobos', I think it should eventually be moved to
'com.XXXXX.phobos', once its development has become a community effort rather
than being primarily under Walter's control.
  </pre>
</blockquote>
<p class="MsoNormal"><span lang="EN-US">I like the idea of a repository
for
D.&nbsp; Thanks, Benji!<br>
<br>
My babble,<br>
<br>
I'd be nice if it could be linked in with the editor, so you could have
some
sort of tool, which would do all sorts of fancy stuff with the
repository such
as:</span><span style=""><o:p></o:p></span></p>
<ul type="disc">
  <li style="" class="MsoNormal"><span lang="EN-US">Download updates
and the repository hierarchy in the background (while your
coding).<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Allow searching for
particular types of libraries by keywords, descriptions ect... Allowing
many different types of filters and sort modes.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Automatic
installation of projects when you click on them.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">In the text
editor/source code, you could click on an "import" and go to the help
web page (or anything related to that package).<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Automatically adds
and updates your project (when you say so of cause).<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">All the CVS
stuff.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Links to support
email addresses or even forums.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">List of summited
code samples for the particular project (which like a newsgroup, could
be summited by anyone).<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Informs when new
projects have been added.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">Clicking on an
error caused by a particular project would either take you to the
solution to that error, or allow you to summit a bug
report.<o:p></o:p></span></li>
  <li style="" class="MsoNormal"><span lang="EN-US">If you download one
project, and it needs several others, they would also be
downloaded.<o:p></o:p></span></li>
</ul>
<span style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;"
 lang="EN-US">Anyway, basically, you'd be able to find the lib
you need (without knowing what the libraries name was to begin with),
and download
and install it into the current project in a matter of clicks, in the
editor.&nbsp; And then get help with it, in a few more clicks. Actually the
software could probably support a local version of this as well.&nbsp; The
point is, every free library invented for D would almost be as easy to
use, as
if it was already installed on your machine (there would be some extra
$+forms
for commercial products).<br>
<br>
&nbsp;I guess the program would look something like mixture of newsgroup,
personal chat programs and P2P download share programs.<br>
<br>
I wish I had time to do something like that; I'd save even more time
then a web
page repository.&nbsp; Of course, the repository needs to be established
first,
and second, in many cases web page designers put up resistance to
creation of a
software version of their web page (</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;"><span
 lang="EN-US">Benji</span></span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;"
lang="EN-US">?).</span>
</body>
</html>
Sep 15 2003