View previous topic :: View next topic |
Author |
Message |
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Sun Jan 01, 2006 1:26 pm Post subject: Users: show of hands |
|
|
I'm personally looking at DDL as a way of implementing a private project of mine, a server codenamed "Lyra". It has a simple driver program, and its own internal-use programming language (pitifully named "LyraScript", formerly "KiC"). Server modules in the "world tree" (need to rename that...) come in two types... Script modules, *.lyra, written in LyraScript and JIT compiled by the driver... Native modules, *.ddl (!), written in D according to a template, and exposing new functions for use by Script modules.
So three points in this post: 1) how soon (or now!?) can DDL be considered generally useful? 2) what are the precise steps to get a project going with DDL / are these listed somewhere already, like a DDL tutorial? 3) I wonder who else already has plans for DDL? (C'mon Kris, I know you do!) _________________ Chris Nicholson-Sauls |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sun Jan 01, 2006 3:18 pm Post subject: Re: Users: show of hands |
|
|
csauls wrote: | 3) I wonder who else already has plans for DDL? (C'mon Kris, I know you do!) |
I'm not Kris, but I started helping out here because I saw this project as the most likely (and greatest) solution for dynamic loading of plugins in a crossplatform way. Plugins is a general love of mine, but my specific need sprang from looking at Sinbad where one to get any output of use, need some system of looking at available renderers. In OGRE, they just use dynamic libraries (.so and .dll). I think some static constructors and such could do the trick, but using dynamic plugins, a 3rd party could provide a closed plugin implementing the same interface. And it's cooler But not necessarily more efficient. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Jan 01, 2006 8:29 pm Post subject: |
|
|
I'll be using it immediately for two things:
1) the HTTP server and servlet engine. I've been waiting 18 months for some kind of dynamic loading capability
2) the mango.cluster services, which have also been waiting to enable dynamic code-distribution across a network.
As a side note: I think it's crystal clear that Walter exists entirely within a statically-linked world. There's no usable support in D for either dynamic linking (of D aggregates) or true implementation decoupling ~ rather like the original version of Pascal actually, intended only as a teaching aid.
Thus, it is truly great that this project exists. Through it, usage of D will finally become disentangled from the myopic will of its dictator! AH HAHAHA |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sun Jan 01, 2006 9:13 pm Post subject: |
|
|
Odd. Either the site ate my post, or I hit 'Preview' instead...
The remixed version of my reply:
1) Expect V1.1B (the milestone we're working on now) to be most of what's in the final release. V1.2B is slated for portability fixes and anything else that gets left out in 1.1, and the SDK and final release are the next beyond that.
V1.1B is scheduled for a late release in February.
2) The easiest thing you can do is take a look at test/linktest1.d and review the status log here in the forum. There is no offical tutorial yet, as I'm still rounding out the API. I think that'll change after V1.1B, probably as a wiki first, then as a snapshot of the wiki in the SDK.
3) In short, I devised DDL to work around all the issues I had with developing DSP. If you review the status log in that forum, you'll see what I was up against.
I've also kicked around some puggable server concepts with Kris that'll likely materialize as 'Sumac' either under Mango or DSP... or as its own entity.
DDL, to me, is also an effort unto itself. I view it as the starting point for a much richer set of capabilities for the binary side of D, namely: deeper reflection and portable runtime code generation (w/o invoking the compiler). Together, these will feed into ideas like runtime proxy generation, pluggable compiler architectures and broad-based support for developing new languages. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Mon Jan 02, 2006 7:37 am Post subject: |
|
|
I'll be using DDL for my 3d Engine project. I'll be loading plugins and shaders from .ddl files |
|
Back to top |
|
|
Derek Parnell
Joined: 22 Apr 2004 Posts: 408 Location: Melbourne, Australia
|
Posted: Mon Feb 20, 2006 6:06 pm Post subject: Freudo |
|
|
My Freudo project will result in an interpreter for the Euphoria language. I would very much like a lot of the 'built-in' functions to be wriiten in D and compiled to machine code and then loaded into the interpreter as needed at run time. Plus, I'd like to have 3rd party developers create new 'plug-in' functions for the language. To be able to much of this though, the plug-in modules would have to be able to access some internal routines of the interpreter.
So ... can I have the plug-ins access these by name (mangled or not) or do I have to load the plug-in and then pass delegates etc...?
And how can a dynamically loaded library routine access a routine in another dynamically loaded library? Does it have to load it again or what? _________________ --
Derek
skype name: derek.j.parnell |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Feb 21, 2006 9:41 am Post subject: Re: Freudo |
|
|
Derek Parnell wrote: | My Freudo project will result in an interpreter for the Euphoria language. I would very much like a lot of the 'built-in' functions to be wriiten in D and compiled to machine code and then loaded into the interpreter as needed at run time. Plus, I'd like to have 3rd party developers create new 'plug-in' functions for the language. To be able to much of this though, the plug-in modules would have to be able to access some internal routines of the interpreter. |
Well, you're in good company then! My primary motivation for DDL was to fix the issues I had with DSP and dynamic compilation. So far, it looks like DDL 1.0 will be a toolkit aimed at this goal, and a future release may incorporate more explicit compilaiton elements to make this particular task easier.
Quote: |
So ... can I have the plug-ins access these by name (mangled or not) or do I have to load the plug-in and then pass delegates etc...? |
The plugin will be able to access your runtime's symbols by name, w/o any extra interfacing or what-not; just code like you normally would. DDL provides complete transparency for the loaded library. A slick way to leverage this for plugin registration is to simply use the plugin's static this() routine; just call runtime methods/functions to get the job done.
You can also take the more traditional approach and interface with the loaded library/plugin after its linked. Its no different than any plugin architecture really, as you'll have to query the library for a symbol of a known signature (say a known function or class). The framework provided by DDL makes this easy to do by hiding all of D's symbol name mangling.
Quote: |
And how can a dynamically loaded library routine access a routine in another dynamically loaded library? Does it have to load it again or what? |
You will only have to load any dependency once, barring the need to replace it at runtime.
Say you're linking library A, and it depends on library B. There are ways to automate the linking of B first, either via a search-capable loader (like PathLoader) or by explicitly linking B ahead of A. Both techniques have the requirement that library B be 'registered' with the linker, so it may be a source of symbol information for library A.
However, the drawback here is that B becomes a part of the linker from that point forward. If you wish to replace or reload B at runtime, you're stuck and will have to work around it some other way. I plan on having this particular issue resolved sometime post 1.0, as this will impact reload-capable apps like DSP. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|