What's left for 1.0?

[Pragma]

Craig Black wrote:
> So it's possible for DDL to work in Linux.  Are there plans for implementing 
> this in the near future?  If so how long would you expect it to take?

It's in the roadmap, although the milestones are really out of date.

It could be a very long time - weeks going into months - at the current 
level of manpower we have right now.  Lars and I are working on it when 
we have time, but honestly, just grokking the spec (correctly) is going 
to eat up most of that.  Having implemented OMF correctly (I'm pretty 
sure it's stable, it just needs some refactoring and TLC), I don't think 
ELF will take anywhere near as long.

The upside is that the DDL core library is pretty much done.  So the 
worst of it is loading and interpreting an ELF's data correctly.

> Also, it seems that Walter will eventually implement some kind of run-time 
> reflection.  How do you think native reflection would influence DDL?  It 
> seems to me that it would make it easier to do what  you are doing.

Honestly, I don't think Walter is going to go towards runtime 
introspection and reflection when he's so close to getting full 
introspection working great at compile-time.  There are also problems 
with the sheer overhead of symbolic information.  I think we're fare 
more likely to see this as a third-party thing, like a preprocessor that 
emits extra D code to cover where Typeinfo is lacking.

But if D did have such a system in place, the only flaw would be that 
the .exe's compiled-in reflection system would likely be unaware of the 
dynamically loaded parts.  DDL would have to provide a facade that makes 
access to the in-situ (.exe part) and dynamic reflection hooks, seamless. :)

However, I am working on a fairly comprehensive runtime-reflection 
solution as a part of D.  Since DDL's already playing with symbolic 
information, it's not a huge deal to serve it up in a way that's 
searchable and iterable.  The only drawback is that it's limited to what 
gets exposed as symbols, so anything that's compiled into an offset or 
constant (struct/class fields, enums, etc) is lost.  IMO functions, 
methods, modules and classes are adequate for most uses, so I'm going 
ahead with it.

As to what would make it easier to do this, well I don't think 
reflection is the big stumbling block here.  In order, the major hurdles 
have been:

1) Lack of experience (this is my first linker and module file loader)
2) Bad specifications (Just OMF.  ELF has been a godsend by comparison)
3) Lack of working examples (there's Binutils and then there's DDL)
4) Loading & Linking problems are *very* hard to debug.

That said, being able to extract anything useful from linked modules has 
been largely the work of Don and Tomasz.  Actually, it's the one thing 
that folks using the lib have found easiest to improve.

[another long-winded, rambling post by:]
-- 
- EricAnderton at yahoo