• Ted Williams (7/7) Jun 04 2004 It would seem based on the descriptions of import I have seen that in or...
• Walter (5/10) Jun 04 2004 order
• Stephan Wienczny (14/24) Jun 04 2004 You simply strip of everything...
• Ted Williams (9/33) Jun 06 2004 So what you are saying is that I will have to maintain two of everything...
• Walter (4/7) Jun 06 2004 Yes, just like in C++. However, it would be fairly easy to write a D too...
• Ted Williams (8/15) Jun 06 2004 This sounds an aweful lot like header files, which I thought import was
• Arcane Jill (3/7) Jun 06 2004 Well /I'm/ intrigued. Let rip...
• Ted Williams (12/20) Jun 06 2004 OK...what if the compiler, based on a switch, would generate a pre-compi...
• Stephan Wienczny (8/46) Jun 06 2004 I think it would be easier to do it the way Walter suggested.
• Martin M. Pedersen (8/10) Jun 06 2004 pre-compiled
• Ilya Minkov (24/29) Jun 07 2004 is
• J C Calvarese (9/43) Jun 07 2004 Some of dig has accumulated some dust since Burton Radons stopped
• Walter (6/16) Jun 09 2004 pre-compiled
• Walter (3/6) Jun 09 2004 Import does eliminate the need for it, unless you want to hide the sourc...
• Marco A (4/11) Jun 09 2004 Effiel does it this way, it has "short"

"Ted Williams" <ted.wil.no.spam verizon.net> writes:

It would seem based on the descriptions of import I have seen that in order
to link to a library written in D You need to have access to the source of
the library at the time you are compiling the client.  How does this work
for commercial software where it is undesirable for the user to have access
to the full source of the library?

Thanks,
Ted

"Walter" <newshound digitalmars.com> writes:

"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:c9qim8$1hq2$1 digitaldaemon.com...
 It would seem based on the descriptions of import I have seen that in

order
 to link to a library written in D You need to have access to the source of
 the library at the time you are compiling the client.  How does this work
 for commercial software where it is undesirable for the user to have

access
 to the full source of the library?

Take a look at std.gc and internal/gc/gc.d for a demonstration.

Stephan Wienczny <wienczny web.de> writes:

You simply strip of everything...
Imports don't have to contain the full source code. All you have to 
provide are the declarations.

module A;

void _func();

module B;
import A;

int main(char[][] argv)
{
	_func();
	return 0;
}

Now you will have to link against the object file that contains A.

Ted Williams wrote:
 It would seem based on the descriptions of import I have seen that in order
 to link to a library written in D You need to have access to the source of
 the library at the time you are compiling the client.  How does this work
 for commercial software where it is undesirable for the user to have access
 to the full source of the library?
 
 Thanks,
 Ted
 
 

"Ted Williams" <ted.wil.no.spam verizon.net> writes:

So what you are saying is that I will have to maintain two of everything?
One version with the full source to compile the library and one "stripped"
version with just declarations?

"Stephan Wienczny" <wienczny web.de> wrote in message
news:c9qjkc$1j42$1 digitaldaemon.com...
 You simply strip of everything...
 Imports don't have to contain the full source code. All you have to
 provide are the declarations.

 module A;

 void _func();

 module B;
 import A;

 int main(char[][] argv)
 {
 _func();
 return 0;
 }

 Now you will have to link against the object file that contains A.

 Ted Williams wrote:
 It would seem based on the descriptions of import I have seen that in


order
 to link to a library written in D You need to have access to the source


of
 the library at the time you are compiling the client.  How does this


work
 for commercial software where it is undesirable for the user to have


access
 to the full source of the library?

 Thanks,
 Ted

"Walter" <newshound digitalmars.com> writes:

"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:c9uopb$1hkl$1 digitaldaemon.com...
 So what you are saying is that I will have to maintain two of everything?
 One version with the full source to compile the library and one "stripped"
 version with just declarations?

Yes, just like in C++. However, it would be fairly easy to write a D tool to
take the source and 'strip' it.

"Ted Williams" <ted.wil.no.spam verizon.net> writes:

This sounds an aweful lot like header files, which I thought import was
supposed to eliminiate the need for.  I have a solution in mind if you'd
like to hear it.

"Walter" <newshound digitalmars.com> wrote in message
news:c9vn3c$2qod$1 digitaldaemon.com...
 "Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
 news:c9uopb$1hkl$1 digitaldaemon.com...
 So what you are saying is that I will have to maintain two of


everything?
 One version with the full source to compile the library and one


"stripped"
 version with just declarations?

 Yes, just like in C++. However, it would be fairly easy to write a D tool

to
 take the source and 'strip' it.

Arcane Jill <Arcane_member pathlink.com> writes:

In article <c9vv4i$4ao$1 digitaldaemon.com>, Ted Williams says...
This sounds an aweful lot like header files, which I thought import was
supposed to eliminiate the need for.

It's the price you pay for not being open-source.


I have a solution in mind if you'd
like to hear it.

Well /I'm/ intrigued. Let rip...

"Ted Williams" <ted.wil.no.spam verizon.net> writes:

OK...what if the compiler, based on a switch, would generate a pre-compiled
"module" file from the source file it is compiling.  Whenever a module is
referenced via import, first this pre-comled file would be searched for and
used if found, otherwise the corresponding source file would be imported as
is now.

So, to compile a library module I might have:

    dmd -c -genimport myModule.d        Generates object and import file
myModule.imp for myModule.d

Then, when the libary is shipped, only the .imp files are sent with it.

Probably there is a better solution, but this is my stab at it.

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca00rh$6tk$1 digitaldaemon.com...
 In article <c9vv4i$4ao$1 digitaldaemon.com>, Ted Williams says...
This sounds an aweful lot like header files, which I thought import was
supposed to eliminiate the need for.

 It's the price you pay for not being open-source.


I have a solution in mind if you'd
like to hear it.

 Well /I'm/ intrigued. Let rip...

Stephan Wienczny <wienczny web.de> writes:

I think it would be easier to do it the way Walter suggested.
You could have a small tool that removes every implementation from the 
sources and copys it into a new import tree.
You would like to have precompiled files. Could you please explain how 
the one you are selling your lib should know whats in you lib? If you 
have a plain source file you can look there...

Stephan

Ted Williams wrote:
 OK...what if the compiler, based on a switch, would generate a pre-compiled
 "module" file from the source file it is compiling.  Whenever a module is
 referenced via import, first this pre-comled file would be searched for and
 used if found, otherwise the corresponding source file would be imported as
 is now.
 
 So, to compile a library module I might have:
 
     dmd -c -genimport myModule.d        Generates object and import file
 myModule.imp for myModule.d
 
 Then, when the libary is shipped, only the .imp files are sent with it.
 
 Probably there is a better solution, but this is my stab at it.
 
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:ca00rh$6tk$1 digitaldaemon.com...
 
In article <c9vv4i$4ao$1 digitaldaemon.com>, Ted Williams says...

This sounds an aweful lot like header files, which I thought import was
supposed to eliminiate the need for.

It's the price you pay for not being open-source.



I have a solution in mind if you'd
like to hear it.

Well /I'm/ intrigued. Let rip...

 
 
 

"Martin M. Pedersen" <martin moeller-pedersen.dk> writes:

"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:ca01jj$7vg$1 digitaldaemon.com...
 OK...what if the compiler, based on a switch, would generate a

pre-compiled
 "module" file from the source file it is compiling.

I don't know if it is feasable, but it would be simpler if a compiled object
file could be imported directly. My idea is to store the needed information
in the object file along with the code, but in such a way that the linker
will ignore it. It could be stored in some binary pre-compiled format, or
simply as stripped-down source text that the parser can use.

Ilya Minkov <minkov cs.tum.edu> writes:

Ted Williams schrieb:

 OK...what if the compiler, based on a switch, would generate a pre-comp=

iled
 "module" file from the source file it is compiling.  Whenever a module =

is
 referenced via import, first this pre-comled file would be searched for=

 and
 used if found, otherwise the corresponding source file would be importe=

d as
 is now.

If i recall correctly, Walter's original plan involved caching an=20
intermediate representation for modules in a binary format, which would=20
as a side effect allow to do the same you propose. However, the parser=20
has turned out so fast, that this feature lost most of its technical=20
motivation and has been put off. Maybe Walter would implement something=20
like that in the first commercial D compiler.

Naturally, if you liked you could take the source and implement the=20
feature. However, this doesn't mean that the implementation would be=20
accepted by the distributions, and there's another aspect: the=20
implementation would be public, so as soon as D gains more users, tools=20
will start to appear which would regain major parts of the source code=20
from th=EDs representation. From some point of popularity, roughly the=20
same would happen even with format being closed. Besides, when you do a=20
binary-only distribution, you can make it for a limited number of=20
compilers and operating systems, thus some people won't be able to use=20
it. So i see some people sell their libraries with source.

digc compiler driver (a neat tool by itself: see undig at dsource) can=20
do stripped versions ("headers") of libraries.

-eye

J C Calvarese <jcc7 cox.net> writes:

Ilya Minkov wrote:
 Ted Williams schrieb:
 
 OK...what if the compiler, based on a switch, would generate a 
 pre-compiled
 "module" file from the source file it is compiling.  Whenever a module is
 referenced via import, first this pre-comled file would be searched 
 for and
 used if found, otherwise the corresponding source file would be 
 imported as
 is now.

 
 
 If i recall correctly, Walter's original plan involved caching an 
 intermediate representation for modules in a binary format, which would 
 as a side effect allow to do the same you propose. However, the parser 
 has turned out so fast, that this feature lost most of its technical 
 motivation and has been put off. Maybe Walter would implement something 
 like that in the first commercial D compiler.
 
 Naturally, if you liked you could take the source and implement the 
 feature. However, this doesn't mean that the implementation would be 
 accepted by the distributions, and there's another aspect: the 
 implementation would be public, so as soon as D gains more users, tools 
 will start to appear which would regain major parts of the source code 
    "Walter" <newshound digitalmars.com>  writes:
"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:ca01jj$7vg$1 digitaldaemon.com...
 OK...what if the compiler, based on a switch, would generate a

pre-compiled
 "module" file from the source file it is compiling.  Whenever a module is
 referenced via import, first this pre-comled file would be searched for

and
 used if found, otherwise the corresponding source file would be imported

as
 is now.

 So, to compile a library module I might have:

     dmd -c -genimport myModule.d        Generates object and import file
 myModule.imp for myModule.d

 Then, when the libary is shipped, only the .imp files are sent with it.

 Probably there is a better solution, but this is my stab at it.

That's really no different from a 'strip' utility.

 Jun 09 2004

    "Walter" <newshound digitalmars.com>  writes:
"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:c9vv4i$4ao$1 digitaldaemon.com...
 This sounds an aweful lot like header files, which I thought import was
 supposed to eliminiate the need for.  I have a solution in mind if you'd
 like to hear it.

Import does eliminate the need for it, unless you want to hide the source.

 Jun 09 2004

    Marco A <Marco_member pathlink.com>  writes:
In article <c9vn3c$2qod$1 digitaldaemon.com>, Walter says...
"Ted Williams" <ted.wil.no.spam verizon.net> wrote in message
news:c9uopb$1hkl$1 digitaldaemon.com...
 So what you are saying is that I will have to maintain two of everything?
 One version with the full source to compile the library and one "stripped"
 version with just declarations?

Yes, just like in C++. However, it would be fairly easy to write a D tool to
take the source and 'strip' it.

Effiel does it this way, it has "short" 
Putting both the interface and the implementation in a single file doesn't mean
those separate concepts go away 

 Jun 09 2004