www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - running DWT with DDL

reply Frank Benoit <keinfarbton googlemail.com> writes:
There is great progress with DDL.

Tom S figured out, how to make it possible to load D classes transparently.
http://h3.team0xf.com/ddlDWT.7z

The problem of what to link against, is solved by having a loader 
application (Host.exe). This loades the DWT.lib and the application 
(also as a lib)

This is a proof of concept. It is not ready for practical use.

host.exe : 1.3  Mb
app.lib  : 0.16 Mb (Texteditor example)
dwt.lib  : 6.6  Mb

the host.exe can be either always the same and start the application 
passed as a commandline arg, or the host can be compiled with the 
application imported via import("app.lib").

I am looking forward to see this in a stable framework with integration 
into the D toolchain. Hopefully some day with linux support also.

Thank you Tom, for this nice demonstration

Frank
May 28 2008
next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Perhaps a little background info might be useful. Frank had a few rather 
tricky requirements:

1. There is a large library which should be shared across applications
2. There are plugins to the library
3. Applications must be able to derive classes from the ones in plugins
4. Plugin implementations may be changed post-deployment. In other 
words, the app may not know the source or binary code of the plugins in 
advance.

1. itself is a tough issue on Windows, as DLLs are not D - friendly.
2, 3, and 4 mean that the application has classes whose code parts are 
not known until the plugins are loaded. While it might be solved with 
some fancy design patterns, it would be nice if the setup worked out of 
the box without any hacking around.

But how can we have an executable that derives from classes whose 
implementation is not known - it's in .di files? As far as I know, one 
can't have incomplete executables on Windows or Linux. (executables with 
unresolved symbols).

Here's where DDL steps in. There are perhaps more solutions, but we've 
employed a version where there's a 'host' executable that loads the 
application, the lib (and potentially the plugins) dynamically. The host 
links them all together using DDL and then starts the app. As a result, 
we only have one executable (and as Frank said, it can be shared across 
apps) and lots of libs that are loaded thru DDL. As libs may be 
incomplete, all problems are solved right away.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
May 28 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Tom,


 Perhaps a little background info might be useful. Frank had a few
 rather tricky requirements:
 
 1. There is a large library which should be shared across applications
 2. There are plugins to the library
 3. Applications must be able to derive classes from the ones in
 plugins
 4. Plugin implementations may be changed post-deployment. In other
 words, the app may not know the source or binary code of the plugins
 in
 advance.
 1. itself is a tough issue on Windows, as DLLs are not D - friendly.
 2, 3, and 4 mean that the application has classes whose code parts are
 not known until the plugins are loaded. While it might be solved with
 some fancy design patterns, it would be nice if the setup worked out
 of
 the box without any hacking around.
 But how can we have an executable that derives from classes whose
 implementation is not known - it's in .di files? As far as I know, one
 can't have incomplete executables on Windows or Linux. (executables
 with unresolved symbols).
 
 Here's where DDL steps in. There are perhaps more solutions, but we've
 employed a version where there's a 'host' executable that loads the
 application, the lib (and potentially the plugins) dynamically. The
 host links them all together using DDL and then starts the app. As a
 result, we only have one executable (and as Frank said, it can be
 shared across apps) and lots of libs that are loaded thru DDL. As libs
 may be incomplete, all problems are solved right away.
 



This is great news!  Tom and Frank, thanks for experimenting with this.

I'm looking forward to seeing this option applied creatively to dwt projects 
(and other D projects).  I can see that this sort of plugin architecture 
could prove quite useful for larger dwt apps like poseidon or even application 
"systems" like eclipse (no D equivalent yet).  This may not necessarily be 
useful for small dwt apps, but I'm sure there are a host of opportunities 
for creative use.  Perhaps from OS kernels to high-level plugin systems.

Great work!

-JJR
May 28 2008
prev sibling parent reply bobef <bobef nospam-abv.bg> writes:
The last time I did that was one year ago with DWT-Shawn and DDL was loading
DWT terribly slow (like 10 seconds on a fast pc). So it was not usable at all.
Is this still the case?

Frank Benoit Wrote:


 There is great progress with DDL.
 
 Tom S figured out, how to make it possible to load D classes transparently.
 http://h3.team0xf.com/ddlDWT.7z
 
 The problem of what to link against, is solved by having a loader 
 application (Host.exe). This loades the DWT.lib and the application 
 (also as a lib)
 
 This is a proof of concept. It is not ready for practical use.
 
 host.exe : 1.3  Mb
 app.lib  : 0.16 Mb (Texteditor example)
 dwt.lib  : 6.6  Mb
 
 the host.exe can be either always the same and start the application 
 passed as a commandline arg, or the host can be compiled with the 
 application imported via import("app.lib").
 
 I am looking forward to see this in a stable framework with integration 
 into the D toolchain. Hopefully some day with linux support also.
 
 Thank you Tom, for this nice demonstration
 
 Frank
May 29 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello bobef,


 The last time I did that was one year ago with DWT-Shawn and DDL was
 loading DWT terribly slow (like 10 seconds on a fast pc). So it was
 not usable at all. Is this still the case?
 


Looks like this has been done a couple of times before, but not necessarily 
with DWT.  Kris submitted the first idea to use the host app about 2 years 
ago; the tool is in ddl svn.  I guess the method didn't catch on... perhaps 
because of load times as you mention, although it's a clever idea. :)

I haven't been able to test the example yet, so I don't know about load times. 
 Frank? Tom?

-JJR
May 29 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
John Reimer wrote:

 Hello bobef,
 

 The last time I did that was one year ago with DWT-Shawn and DDL was
 loading DWT terribly slow (like 10 seconds on a fast pc). So it was
 not usable at all. Is this still the case?


 
 Looks like this has been done a couple of times before, but not 
 necessarily with DWT.  Kris submitted the first idea to use the host app 
 about 2 years ago; the tool is in ddl svn.  I guess the method didn't 
 catch on... perhaps because of load times as you mention, although it's 
 a clever idea. :)
 
 I haven't been able to test the example yet, so I don't know about load 
 times. Frank? Tom?


When first running the app, all deps are loaded, parsed and linked 
within about 3-4 sec on my laptop with centrino 1.7. When running it 
again and the libs are cached by the OS, it's about 1-2 seconds. This 
includes loading tango-base, tango-user, a dozen of winapi libs, the app 
and the dwt lib.
I'm planning to optimize the omf backend in ddl more, so these numbers 
can be expected to shrink :)


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
May 29 2008