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




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.


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:
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




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).



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



 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)




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 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:


"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




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.


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




 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.


 
 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




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.


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


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.


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


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.

That does sound pretty cool.


 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.


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


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).


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


not

 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