D - A few questions
- Helmut Leitner (25/25) Mar 31 2003 (1) I found two windows.d modules:
- Walter (13/35) Mar 31 2003 Use one or the other. They should be merged into one.
- Matthew Wilson (10/45) Mar 31 2003 Sorry to be a dope on this issue, and I _know_ I should have digested
- Helmut Leitner (20/67) Mar 31 2003 Could a leading '.' interpreted like a leading "\" or "/" as
- Helmut Leitner (7/27) Apr 01 2003 To clarify: I don't plan to produce proprietary or closed source
- Burton Radons (6/14) Apr 01 2003 You can use digc (at http://www.opend.org/dig/) for that - when it
- Helmut Leitner (11/27) Apr 01 2003 Is this done by dstrip, Matthew Wilson is just talking about?
- Burton Radons (11/39) Apr 02 2003 Yup.
(1) I found two windows.d modules:
- a part of Phobos (50 K)
- a rather complete Win32 API interface by Pavel
How are they meant to interact?
Does it make sense to have these identically named modules?
(2) import seems to be modeled after the Java so that
"c.stdio" translates to ROOT\c\stdio.d
How can modules from other arbitrary paths be included?
What is the rationale of not allowing someone of these
import c\stdio;
import c/stdio;
import d:\mylib\xyz;
import c:\dmd\src\phobos c\stdio;
or anything like that to allow whatever path a programmer
prefers?
(3) When I do an
import c.stdio;
the source file c\stdio.d is read.
So I really have to supply the source?
Why isn't the compiled objectfile enough?
What if I just want to deliver a library without
the module sources?
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com
Mar 31 2003
"Helmut Leitner" <helmut.leitner chello.at> wrote in message news:3E889DFF.941BFED6 chello.at...(1) I found two windows.d modules: - a part of Phobos (50 K) - a rather complete Win32 API interface by Pavel How are they meant to interact? Does it make sense to have these identically named modules?Use one or the other. They should be merged into one.(2) import seems to be modeled after the Java so that "c.stdio" translates to ROOT\c\stdio.d How can modules from other arbitrary paths be included?The -I switch can be used to set the ROOT.What is the rationale of not allowing someone of these import c\stdio; import c/stdio; import d:\mylib\xyz; import c:\dmd\src\phobos c\stdio; or anything like that to allow whatever path a programmer prefers?They'll make the source code non-portable, as well as not being tokenizable.(3) When I do an import c.stdio; the source file c\stdio.d is read.Yes.So I really have to supply the source?Enough of it to supply the declarations you intend to use from it.Why isn't the compiled objectfile enough?Because the object file is missing most of the symbolic information.What if I just want to deliver a library without the module sources?Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.
Mar 31 2003
"Matthew Wilson" <dmd synesis.com.au> Sorry to be a dope on this issue, and I _know_ I should have digested Burton's reply to my earlier post on this, but maybe having something on the D website that shows how to adapt a library source to obj+declarations would be useful. Of course, I could be doing my usual and shooting before researching. If it's already there, please just give me the url, and take it as read that my cheeks will be red. :) "Walter" <walter digitalmars.com> wrote in message news:b6anti$1c91$1 digitaldaemon.com..."Helmut Leitner" <helmut.leitner chello.at> wrote in message news:3E889DFF.941BFED6 chello.at...tokenizable.(1) I found two windows.d modules: - a part of Phobos (50 K) - a rather complete Win32 API interface by Pavel How are they meant to interact? Does it make sense to have these identically named modules?Use one or the other. They should be merged into one.(2) import seems to be modeled after the Java so that "c.stdio" translates to ROOT\c\stdio.d How can modules from other arbitrary paths be included?The -I switch can be used to set the ROOT.What is the rationale of not allowing someone of these import c\stdio; import c/stdio; import d:\mylib\xyz; import c:\dmd\src\phobos c\stdio; or anything like that to allow whatever path a programmer prefers?They'll make the source code non-portable, as well as not being(3) When I do an import c.stdio; the source file c\stdio.d is read.Yes.So I really have to supply the source?Enough of it to supply the declarations you intend to use from it.Why isn't the compiled objectfile enough?Because the object file is missing most of the symbolic information.What if I just want to deliver a library without the module sources?Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.
Mar 31 2003
Walter wrote:"Helmut Leitner" <helmut.leitner chello.at> wrote in message news:3E889DFF.941BFED6 chello.at......to set multiple ROOTs?(1) I found two windows.d modules: - a part of Phobos (50 K) - a rather complete Win32 API interface by Pavel How are they meant to interact? Does it make sense to have these identically named modules?Use one or the other. They should be merged into one.(2) import seems to be modeled after the Java so that "c.stdio" translates to ROOT\c\stdio.d How can modules from other arbitrary paths be included?The -I switch can be used to set the ROOT.Could a leading '.' interpreted like a leading "\" or "/" as indicator of an absolute path import .dmd.src.phobos.c.stdio solve this?What is the rationale of not allowing someone of these import c\stdio; import c/stdio; import d:\mylib\xyz; import c:\dmd\src\phobos c\stdio; or anything like that to allow whatever path a programmer prefers?They'll make the source code non-portable, as well as not being tokenizable.Even if compiled for debug?(3) When I do an import c.stdio; the source file c\stdio.d is read.Yes.So I really have to supply the source?Enough of it to supply the declarations you intend to use from it.Why isn't the compiled objectfile enough?Because the object file is missing most of the symbolic information.But that leaves as in a situation similar to C. Prepare a "header" file separate from the source. More exactly, it adds a task to the D community task list: - D2DI, a tool to create a pure interface file And it may force us to have two different files in our systems that have the same name but different content. Could there be a solution for this? Looking for "module.di" if "module.d" is not found? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.comWhat if I just want to deliver a library without the module sources?Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.
Mar 31 2003
Helmut Leitner wrote:To clarify: I don't plan to produce proprietary or closed source D libraries or modules. I'm only evaluating D and I try to check which of our typical projects or products could be done in D. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.comBut that leaves as in a situation similar to C. Prepare a "header" file separate from the source. More exactly, it adds a task to the D community task list: - D2DI, a tool to create a pure interface file And it may force us to have two different files in our systems that have the same name but different content. Could there be a solution for this? Looking for "module.di" if "module.d" is not found?What if I just want to deliver a library without the module sources?Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.
Apr 01 2003
Helmut Leitner wrote:
(3) When I do an
import c.stdio;
the source file c\stdio.d is read.
So I really have to supply the source?
Why isn't the compiled objectfile enough?
What if I just want to deliver a library without
the module sources?
You can use digc (at http://www.opend.org/dig/) for that - when it
compiles libraries (with the -lib= option) it appends the stripped
import files and recreates them when the library is used. The .lib
file, and .dll if you gave a -shared option, is all the binaries you
need to distribute.
Apr 01 2003
Burton Radons wrote:Helmut Leitner wrote:Is this done by dstrip, Matthew Wilson is just talking about? Does this mean that stripped module.d files become part of the library? ... and are (a) used by the dmd from within the library or (b) extracted from to library before being used by dmd ? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com(3) When I do an import c.stdio; the source file c\stdio.d is read. So I really have to supply the source? Why isn't the compiled objectfile enough? What if I just want to deliver a library without the module sources?You can use digc (at http://www.opend.org/dig/) for that - when it compiles libraries (with the -lib= option) it appends the stripped import files and recreates them when the library is used. The .lib file, and .dll if you gave a -shared option, is all the binaries you need to distribute.
Apr 01 2003
Helmut Leitner wrote:Burton Radons wrote:It's not a separate utility, just a small module in digc.Helmut Leitner wrote:Is this done by dstrip, Matthew Wilson is just talking about?(3) When I do an import c.stdio; the source file c\stdio.d is read. So I really have to supply the source? Why isn't the compiled objectfile enough? What if I just want to deliver a library without the module sources?You can use digc (at http://www.opend.org/dig/) for that - when it compiles libraries (with the -lib= option) it appends the stripped import files and recreates them when the library is used. The .lib file, and .dll if you gave a -shared option, is all the binaries you need to distribute.Does this mean that stripped module.d files become part of the library?Yup.... and are (a) used by the dmd from within the library or (b) extracted from to library before being used by dmd ?digc maintains a dictionary of libraries in \dmd\lib and updates it with the import statements that should match. When compiling code, it searches the source for matching import statements; if they exist, it drops the stripped source of the library in a temporary directory, then removes it after compilation. This is done very quickly, and the next release will double stripping speed. So DMD is completely unaware. I'll repeat my reasons why in the response to Matthew's message.
Apr 02 2003