On 22/10/2009 18:52, BCS wrote:
Hello Yigal,
On 22/10/2009 00:57, BCS wrote:
Hello Yigal,
As you said, what is needed is a better lib format. we already have
DDL NOW which already has most of what you described above. D can
also take advantage of the LLVM framework.
Does DDL or LLVM work to generate monolithic executable that use all
of D's features and do so for both Win32 and *nux?
Also, can I use notepad to view either of those file types?
from http://llvm.org/docs/LangRef.html
<quote>
The LLVM code representation is designed to be used in three different
forms: as an in-memory compiler IR, as an on-disk bitcode
representation (suitable for fast loading by a Just-In-Time compiler),
and as a human readable assembly language representation. This allows
LLVM to provide a powerful intermediate representation for efficient
compiler transformations and analysis, while providing a natural means
to debug and visualize the transformations. The three different forms
of LLVM are all equivalent.
</quote>
So, if your library has LLVM code representation, then it's easier to
get to but just as bad as reading a ASM dump from the compiler.
I'm being more than a bit sarcastic there, but keep in mind that 99% of
the info I'm interested in isn't in the assembly code (function names,
argument names, types, comments) and/or would be better viewed as the
original source.
even though it looks like ASM it is not the same. the llvm will contain
the info (function names, argument names, types, comments) as metadata.
visual studio has a view to see all metadata in an assembly, and D IDEs
will implement a similar properties view to show the same info.
comparing to original source is useless - commercial companies may want
to protect their commercial secrets and provide you with only a binary
file and the bare minimum to use that file in your projects. D needs to
support that option. of course it would be wonderfull if everything
would be open-source but D can't force this on everyone and if we want D
to be mainstream it needs to support such paradigms as well.
IIRC DDL wraps objects/libs with meta-data.
while it will be easy to get a text representation with llvm (the
equivalence that is mentioned above) why would you want to do it
anyway? Automatically extracted documentation to a human format (ddoc,
javadoc, etc) is much more useful and more flexible - you can get a
printed manual or an interactive and easy to navigate html, you can
also get all sorts of graphs and diagrams that would ease
understanding of the structure of code.
I'm cynical enough that I'd bet if D switches to a "smarter lib format"
a lot of people would manage to forget the documentation.
With the current system, the library must be shipped with, at a minimum,
a human readable list of prototypes.
without proper documentation people will have no way to know how to use
such libraries. givven that D has DDoc to automate this process I'd say
it'll encorage developers to provide proper documentation instead of
just saying - go read the headers/source.
the only valid IMO use case for header files is for linking libs - the
compiler can handle just find binary formats for that.
Truth be told I don't use .di files at all because I have yet to need to
use a codebase where I didn't have full source.
that doesn't reflect the needs of everyone.
