www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.134 release (Ddoc update)

reply "Walter Bright" <newshound digitalmars.com> writes:
Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due to
all the suggestions.

http://www.digitalmars.com/d/changelog.html
Sep 28 2005
next sibling parent reply =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= <araelx gmail.com> writes:
On Thu, 29 Sep 2005 08:25:40 +0200, Walter Bright  
<newshound digitalmars.com> wrote:

 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due to
 all the suggestions.

Shouldn't there be sections like "Todo:", "Note:" in DDoc? They could be useful I think. BTW I've got a questions. Currently ddoc generates rather simple documentation. Is it going to be simple but efficient way of documentation D or plan is to grow into crossreference doc generator like let say Doxygen. -- Dawid Ciężarkiewicz
Sep 29 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Dawid Ciezarkiewicz" <araelx gmail.com> wrote in message
news:op.sxvj9hny58xlqs localhost.localdomain...
 On Thu, 29 Sep 2005 08:25:40 +0200, Walter Bright
 <newshound digitalmars.com> wrote:

 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due


 all the suggestions.

Shouldn't there be sections like "Todo:", "Note:" in DDoc? They could be useful I think. BTW I've got a questions. Currently ddoc generates rather simple documentation. Is it going to be simple but efficient way of documentation D or plan is to grow into crossreference doc generator like let say Doxygen.

Certainly Ddoc will grow in capability. But it's already a big productivity booster for writing documentation.
Sep 29 2005
prev sibling next sibling parent reply Markus Dangl <danglm in.tum.de> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Walter Bright wrote:
 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due to
 all the suggestions.
 
 http://www.digitalmars.com/d/changelog.html

This works much better for XML output. I still have one problem, though: Colons appearing in the text are problematic, i experienced it with some smilies in my docs. I attached an example d source plus ddoc definition, where the ddoc generator puts the bracket following the smily in some strange place... Briefly described: If a colon appears in the ddoc text, for example: /** * Bugs: This functions is useless :) */ void useless() { } Then ddoc will put a bracket in the output, right after the last DDOC_DECL_DD. I'm still working on XML output, and i think i'll do a nice example of XML to XHTML and XML to XSL-FO conversion, so you can have your docs exported to PDF (for example using Apache FOP).
Sep 29 2005
next sibling parent "Kris" <fu bar.com> writes:
I'll echo that sentiment -- people use all manner of (natural) language
constructs within the documentation proper; including (gasp) punctuation.
There's seven different uses of punctuation within this paragraph alone: I'd
be horrified to find any of it being treated as "section names".

:)



"Markus Dangl" <danglm in.tum.de> wrote in message
news:dhhpaj$6lu$1 digitaldaemon.com...
 Walter Bright wrote:
 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due


 all the suggestions.

 http://www.digitalmars.com/d/changelog.html

This works much better for XML output. I still have one problem, though: Colons appearing in the text are problematic, i experienced it with some smilies in my docs. I attached an example d source plus ddoc definition, where the ddoc generator puts the bracket following the smily in some strange place... Briefly described: If a colon appears in the ddoc text, for example: /** * Bugs: This functions is useless :) */ void useless() { } Then ddoc will put a bracket in the output, right after the last DDOC_DECL_DD. I'm still working on XML output, and i think i'll do a nice example of XML to XHTML and XML to XSL-FO conversion, so you can have your docs exported to PDF (for example using Apache FOP).

---------------------------------------------------------------------------- ----
 DDOC =<body>$(BODY)</body>
 DDOC_DECL      =
 DDOC_DECL_DD   = <desc>$0</desc>
 DDOC_SECTIONS  = $0
 DDOC_SUMMARY   =
 DDOC_DESCRIPTION =
 DDOC_SECTION_H =
 DDOC_SECTION   =
 DDOC_MEMBERS   = $0
 DDOC_PARAMS    = <params>$0</params>
 DDOC_PARAM_ROW = <row>$0</row>
 DDOC_PARAM_ID  = <id>$0</id>
 DDOC_PARAM_DESC  = <pdesc>$0</pdesc>
 DDOC_PSYMBOL  =
 DDOC_KEYWORD  =
 DDOC_PARAM    =
 DDOC_AUTHORS   =
 DDOC_BUGS      =
 DDOC_COPYRIGHT =
 DDOC_DATE      =
 DDOC_DEPRECATED =
 DDOC_EXAMPLES  =
 DDOC_HISTORY   =
 DDOC_LICENSE   =
 DDOC_RETURNS   =
 DDOC_SEE_ALSO  =
 DDOC_STANDARDS =
 DDOC_THROWS    =
 DDOC_VERSION   =
 D_CODE =
 B = $0
 I = $0
 U = $0
 P = $0
 DL = $0
 DT = $0
 DD = $0
 TABLE = $0
 TR = $0
 TH = $0
 TD = $0
 OL = $0
 UL = $0
 LI = $0
 BIG = $0
 SMALL = $0
 BR = $0
 RED = $0
 BLUE =  $0
 GREEN = $0
 YELLOW = $0
 BLACK = $0
 WHITE = $0
 LINK = $0
 LINK2 = $+

---------------------------------------------------------------------------- ----
 /**
  * The smilie in the description of parameter "c"
  * causes ddoc to put a bracket where no bracket belongs...
  *
  * Seems like colons are problematic...
  *
  * Params:
  *      a = Some int value.
  *      b = You may pass any char
  *          but it will never be used
  *          anyways.
  *      c = A double value :)
  */
 void foo3(int a, char b, double c)
 {
 }

 int main(char[][] args)
 {
 }

Sep 29 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
The problem isn't the :. It's the ). The macro process sees the ) and
considers it the end of the macro invocation.

To fix, add the macro definition:

    RPAREN=)

and then the smily becomes:

    :$(RPAREN)
Sep 29 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 29 Sep 2005 17:53:07 -0700, Walter Bright wrote:

 The problem isn't the :. It's the ). The macro process sees the ) and
 considers it the end of the macro invocation.
 
 To fix, add the macro definition:
 
     RPAREN=)
 
 and then the smily becomes:
 
     :$(RPAREN)

Or SMILEY=:) then use /** * Bugs: This functions is useless $(SMILEY) */ -- Derek (skype: derek.j.parnell) Melbourne, Australia 30/09/2005 12:01:56 PM
Sep 29 2005
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
Pardon the naiive question, but does this mean one cannot (naturally) use
parens (or some other manner of punctuation) within documentation?

- Kris


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dhi5u2$fl1$1 digitaldaemon.com...
 The problem isn't the :. It's the ). The macro process sees the ) and
 considers it the end of the macro invocation.

 To fix, add the macro definition:

     RPAREN=)

 and then the smily becomes:

     :$(RPAREN)

Sep 29 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 29 Sep 2005 19:21:41 -0700, Kris wrote:

 Pardon the naiive question, but does this mean one cannot (naturally) use
 parens (or some other manner of punctuation) within documentation?

Not quite... You can't use *unmatched* parenthesis easily. For instance if you have ... /** This module is the greatest thing since sliced bread (tm) according to my mother. */ Then you will have no problems. But if you had coded 'tm)' or '(tm' instead, you get issues. The reason is that your text gets inserted into one of the predefined macros this ... $(DDOC_SECTIONS This module is the greatest thing since sliced bread (tm) according to my mother.) And as you can see, the 'tm)' would prematurely end the DDOC_SECTIONS macro and '(tm' would cause the DDOC_SECTIONS macro to extend to the end of the file. -- Derek (skype: derek.j.parnell) Melbourne, Australia 30/09/2005 12:29:01 PM
Sep 29 2005
parent "Kris" <fu bar.com> writes:
Thanks, Derek (and Walter). That clarifies nicely.

- Kris


"Derek Parnell" <derek psych.ward> wrote in message
news:1k5jr85h4w1mq$.n7omn2dakl54.dlg 40tude.net...
 On Thu, 29 Sep 2005 19:21:41 -0700, Kris wrote:

 Pardon the naiive question, but does this mean one cannot (naturally)


 parens (or some other manner of punctuation) within documentation?

Not quite... You can't use *unmatched* parenthesis easily. For instance if you have ... /** This module is the greatest thing since sliced bread (tm) according to my mother. */ Then you will have no problems. But if you had coded 'tm)' or '(tm' instead, you get issues. The reason is that your text gets inserted into one of the predefined macros this ... $(DDOC_SECTIONS This module is the greatest thing since sliced bread (tm) according to my mother.) And as you can see, the 'tm)' would prematurely end the DDOC_SECTIONS

 and '(tm' would cause the DDOC_SECTIONS macro to extend to the end of the
 file.

 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 30/09/2005 12:29:01 PM

Sep 30 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:dhi7fm$glp$1 digitaldaemon.com...
 Pardon the naiive question, but does this mean one cannot (naturally) use
 parens (or some other manner of punctuation) within documentation?

You can if they match. The argument parser counts them. It also skips parens between "", '', or <!-- -->. It's only the stray ones that'll cause a problem.
Sep 29 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
Or you can use &#41; instead of ).

"Walter Bright" <newshound digitalmars.com> wrote in message
news:dhi5u2$fl1$1 digitaldaemon.com...
 The problem isn't the :. It's the ). The macro process sees the ) and
 considers it the end of the macro invocation.

 To fix, add the macro definition:

     RPAREN=)

 and then the smiley becomes:

     :$(RPAREN)

Sep 29 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 28 Sep 2005 23:25:40 -0700, Walter Bright wrote:

 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due to
 all the suggestions.
 
 http://www.digitalmars.com/d/changelog.html

I'm having a lot of trouble getting the 'Copyright:' section to show up. In fact, I cannot work out how to do it. -- Derek (skype: derek.j.parnell) Melbourne, Australia 30/09/2005 12:34:43 PM
Sep 29 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1xqvtq2pbycrs$.12nvgnf5vclyi.dlg 40tude.net...
 On Wed, 28 Sep 2005 23:25:40 -0700, Walter Bright wrote:

 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due


 all the suggestions.

 http://www.digitalmars.com/d/changelog.html

I'm having a lot of trouble getting the 'Copyright:' section to show up.

 fact, I cannot work out how to do it.

It should show up as an expansion of the $(COPYRIGHT) macro. The reason for that is that often people like to put the copyright notice in unusual places in the DDOC macro.
Sep 29 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 29 Sep 2005 21:07:48 -0700, Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1xqvtq2pbycrs$.12nvgnf5vclyi.dlg 40tude.net...
 On Wed, 28 Sep 2005 23:25:40 -0700, Walter Bright wrote:

 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due


 all the suggestions.

 http://www.digitalmars.com/d/changelog.html

I'm having a lot of trouble getting the 'Copyright:' section to show up.

 fact, I cannot work out how to do it.

It should show up as an expansion of the $(COPYRIGHT) macro. The reason for that is that often people like to put the copyright notice in unusual places in the DDOC macro.

You misunderstand. I know what it is supposed to do, but I can't work out how to get it to do what it is supposed to do! For example, this doc ... /** A summary line. Author: Me, Myself, and I. Copyright: whatever */ module testdoc; produces this output ... <html><head> <META http-equiv="content-type" content="text/html; charset=utf-8"> <title>testdoc</title> </head><body> <h1>testdoc</h1> <!-- Generated by Ddoc from testdoc.d --> A summary line. <br><br> <b>Author:</b><br><br> Me, Myself, and I. <br><br> <dl></dl> <hr><small>Page generated by <a href="http://www.digitalmars.com/d/ddoc.html">Ddoc</a>.</small> </body></html> Not a copyright in sight. -- Derek (skype: derek.j.parnell) Melbourne, Australia 30/09/2005 2:54:02 PM
Sep 29 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:kt94sqgzcrsc$.19mc3tnw25crk$.dlg 40tude.net...
 On Thu, 29 Sep 2005 21:07:48 -0700, Walter Bright wrote:
 It should show up as an expansion of the $(COPYRIGHT) macro. The reason


 that is that often people like to put the copyright notice in unusual


 in the DDOC macro.

You misunderstand. I know what it is supposed to do, but I can't work out how to get it to do what it is supposed to do! For example, this doc ... /** A summary line. Author: Me, Myself, and I. Copyright: whatever */ module testdoc; produces this output ... <html><head> <META http-equiv="content-type" content="text/html; charset=utf-8"> <title>testdoc</title> </head><body> <h1>testdoc</h1> <!-- Generated by Ddoc from testdoc.d --> A summary line. <br><br> <b>Author:</b><br><br> Me, Myself, and I. <br><br> <dl></dl> <hr><small>Page generated by <a href="http://www.digitalmars.com/d/ddoc.html">Ddoc</a>.</small> </body></html> Not a copyright in sight.

The internal version of the DDOC macro doesn't have a $COPYRIGHT) in it. You'll need to copy the DDOC macro, insert the $(COPYRIGHT) where you want it to be, and store the result in a .ddoc file.
Sep 29 2005
prev sibling parent reply "Kris" <fu bar.com> writes:
Hi Walter,

Can the DDoc parser emit tagged source code (just XML) ?  If it could, it
would enable a 'cottage industry' of formatters and the like ~ removing the
need for Ddoc itself to emit pretty formatting output (which is rather
subjective anyway) in X number of file formats; or do cross-referencing,
color-coding, or whatever.

Theoretically, there would be an XML document emitted per module, replete
with Section identifiers, type info, visibility info, external references,
and so on. In addition, you might provide a set of D classes to construct
and traverse the resultant tree (via the files). This generator/reader pair
would be kept in lockstep (by you), whilst anyone else with an interest
could develop formatters based upon the content exposed via those D classes.

This would, of course, free you from the vagaries of HTML, PostScript, etc.
It would also support the (more) rapid development of cross-referencing
documentation, color-coded/linked source, and many other useful goodies.

The hard part for a formatting/documentation tool is extracting relevant
(i.e. marked up) content from the source code. Once that is done (by you),
then the creativity and abundant talents of the community can be brought to
bear on remaining tasks.

Naturally, it would be great if you were to provide a basic formatting tool
yourself; but by supporting a two stage process you could provide the means
for accellerating the pace quite considerably, as well as opening up the
door to creative avenue. Currently, it appears as though macros are used to
provide for formatting ~ while macros are certainly useful, I suspect we'll
need something more powerful to do cross-referencing and so on (e.g. the D
language itself).

Again, to be most effective this would require some limited form of
annotated/tagged source-code. I understand this notion is something that
Pragma had been considering in the past, and is somewhat related to
avaML  -- http://www.badros.com/greg/JavaML/ -- although the latter was not
at all focused upon documentation, and serves simply an illustration.

My 2 cents.

- Kris



"Walter Bright" <newshound digitalmars.com> wrote in message
news:dhg1dv$1gi2$1 digitaldaemon.com...
 Another extensive update of Ddoc, www.digitalmars.com/d/ddoc.html, due to
 all the suggestions.

 http://www.digitalmars.com/d/changelog.html

Sep 30 2005
next sibling parent Markus Dangl <danglm in.tum.de> writes:
I vote for direct XML output too.

You may want to include a XSL-Stylesheet by default, so you can easily 
view the XML in your browser (just like the HTML output).
Sep 30 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:dhk4u9$29dt$1 digitaldaemon.com...
 Hi Walter,

 Can the DDoc parser emit tagged source code (just XML) ?  If it could, it
 would enable a 'cottage industry' of formatters and the like ~ removing

 need for Ddoc itself to emit pretty formatting output (which is rather
 subjective anyway) in X number of file formats; or do cross-referencing,
 color-coding, or whatever.

I agree, but I think Markus has already produced a template file that will cause the output to be in XML. If this is inadequate, we can fix it.
 Theoretically, there would be an XML document emitted per module, replete
 with Section identifiers, type info, visibility info, external references,
 and so on. In addition, you might provide a set of D classes to construct
 and traverse the resultant tree (via the files). This generator/reader

 would be kept in lockstep (by you), whilst anyone else with an interest
 could develop formatters based upon the content exposed via those D

That does sound pretty cool.
 This would, of course, free you from the vagaries of HTML, PostScript,

 It would also support the (more) rapid development of cross-referencing
 documentation, color-coded/linked source, and many other useful goodies.

 The hard part for a formatting/documentation tool is extracting relevant
 (i.e. marked up) content from the source code. Once that is done (by you),
 then the creativity and abundant talents of the community can be brought

 bear on remaining tasks.

My original goal for open sourcing the front end was so that people could build ancilliary tools out of it. This has turned out to be a more daunting task for third party tool developers than I'd anticipated.
 Naturally, it would be great if you were to provide a basic formatting

 yourself; but by supporting a two stage process you could provide the

 for accellerating the pace quite considerably, as well as opening up the
 door to creative avenue. Currently, it appears as though macros are used

 provide for formatting ~ while macros are certainly useful, I suspect

 need something more powerful to do cross-referencing and so on (e.g. the D
 language itself).

I agree that text macros have their limits. Their main attraction is they are simple to understand and simple to implement.
 Again, to be most effective this would require some limited form of
 annotated/tagged source-code. I understand this notion is something that
 Pragma had been considering in the past, and is somewhat related to
 avaML  -- http://www.badros.com/greg/JavaML/ -- although the latter was

 at all focused upon documentation, and serves simply an illustration.

I'll check it out.
Sep 30 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 "Kris" <fu bar.com> wrote in message news:dhk4u9$29dt$1 digitaldaemon.com...
 
 [snip]

It would also support the (more) rapid development of cross-referencing
documentation, color-coded/linked source, and many other useful goodies.

The hard part for a formatting/documentation tool is extracting relevant
(i.e. marked up) content from the source code. Once that is done (by you),
then the creativity and abundant talents of the community can be brought

to
bear on remaining tasks.

My original goal for open sourcing the front end was so that people could build ancilliary tools out of it. This has turned out to be a more daunting task for third party tool developers than I'd anticipated.

I've said this before, but right here feels like a great spot to reiterate: =P To satisfy your original goal, it would be better to make the front-end a dynamic library with an exposed, simple, C API. This would free third-party tool developers from the "daunting task" of dealing with the C++ classes and the headache of nicking out the back-end functions. It would also allow third-party tool developers to write their tools in the D language, since it can easily interface with C functions/libraries. Some simple, well-defined set of good ol' C structs and C functions should do the trick. DMDFE already exists for this purpose, I know, but what good is it if we have to rely on Ben Hinkle (or future maintainer) to consistently update it? No offense to Ben, of course - he's doing a fantastic job and has lots of D-related projects going on. BTW, it should be a dynamic library (DLL, SO) so as to use the host OS's native binary format to handle symbolic linking instead of dealing with static libs and the COFF vs. OMF incompatibilities.
 
 [snip]
 

Oct 03 2005
parent reply JT <jtd514 ameritech.net> writes:
well, ive turned the DMEFE into a C library with a small D API wrapper. 
it works pretty nice. but since D doesnt support dynamic libraries Im 
not sure what you are saying. are you talking about a DMEFE DLL designed 
for use with something like C++? because until DDL gets its feet I dont 
see how dynamic libs are usefull in D


James Dunne wrote:
 Walter Bright wrote:
 
 "Kris" <fu bar.com> wrote in message 
 news:dhk4u9$29dt$1 digitaldaemon.com...

 [snip]

>
 It would also support the (more) rapid development of cross-referencing
 documentation, color-coded/linked source, and many other useful goodies.

 The hard part for a formatting/documentation tool is extracting relevant
 (i.e. marked up) content from the source code. Once that is done (by 
 you),
 then the creativity and abundant talents of the community can be brought

to
 bear on remaining tasks.

My original goal for open sourcing the front end was so that people could build ancilliary tools out of it. This has turned out to be a more daunting task for third party tool developers than I'd anticipated.

I've said this before, but right here feels like a great spot to reiterate: =P To satisfy your original goal, it would be better to make the front-end a dynamic library with an exposed, simple, C API. This would free third-party tool developers from the "daunting task" of dealing with the C++ classes and the headache of nicking out the back-end functions. It would also allow third-party tool developers to write their tools in the D language, since it can easily interface with C functions/libraries. Some simple, well-defined set of good ol' C structs and C functions should do the trick. DMDFE already exists for this purpose, I know, but what good is it if we have to rely on Ben Hinkle (or future maintainer) to consistently update it? No offense to Ben, of course - he's doing a fantastic job and has lots of D-related projects going on. BTW, it should be a dynamic library (DLL, SO) so as to use the host OS's native binary format to handle symbolic linking instead of dealing with static libs and the COFF vs. OMF incompatibilities.
 [snip]


Oct 03 2005
parent James Dunne <james.jdunne gmail.com> writes:
JT wrote:
 well, ive turned the DMEFE into a C library with a small D API wrapper. 
 it works pretty nice. but since D doesnt support dynamic libraries Im 
 not sure what you are saying. are you talking about a DMEFE DLL designed 
 for use with something like C++? because until DDL gets its feet I dont 
 see how dynamic libs are usefull in D
 
 
 James Dunne wrote:
 
 Walter Bright wrote:

 "Kris" <fu bar.com> wrote in message 
 news:dhk4u9$29dt$1 digitaldaemon.com...

 [snip]

>
 It would also support the (more) rapid development of cross-referencing
 documentation, color-coded/linked source, and many other useful 
 goodies.

 The hard part for a formatting/documentation tool is extracting 
 relevant
 (i.e. marked up) content from the source code. Once that is done (by 
 you),
 then the creativity and abundant talents of the community can be 
 brought

to
 bear on remaining tasks.

My original goal for open sourcing the front end was so that people could build ancilliary tools out of it. This has turned out to be a more daunting task for third party tool developers than I'd anticipated.

I've said this before, but right here feels like a great spot to reiterate: =P To satisfy your original goal, it would be better to make the front-end a dynamic library with an exposed, simple, C API. This would free third-party tool developers from the "daunting task" of dealing with the C++ classes and the headache of nicking out the back-end functions. It would also allow third-party tool developers to write their tools in the D language, since it can easily interface with C functions/libraries. Some simple, well-defined set of good ol' C structs and C functions should do the trick. DMDFE already exists for this purpose, I know, but what good is it if we have to rely on Ben Hinkle (or future maintainer) to consistently update it? No offense to Ben, of course - he's doing a fantastic job and has lots of D-related projects going on. BTW, it should be a dynamic library (DLL, SO) so as to use the host OS's native binary format to handle symbolic linking instead of dealing with static libs and the COFF vs. OMF incompatibilities.
 [snip]



I'm talking about doing exactly what you've done, but with equal emphasis on supporting other C/C++ programs in addition to D programs. I'd like to try out what you've done and see what all you've exposed through the C API. Is your work available online somewhere? Well, you are part correct with D's issues with DLLs: D does have issues with creating dynamic libraries in Linux, but not so much anymore with Win32. Upon further thinking on the matter, doesn't Derelict project have Linux code to load up .so's? I'm fairly certain it does via dlopen() and friends. This shouldn't be too much of an issue to write a Derelict-like loader for the DMD front-end library (assuming it's done) in D.
Oct 03 2005