FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Update Forthcoming

 
Post new topic   Reply to topic     Forum Index -> DSP
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Sep 20, 2004 8:27 am    Post subject: Update Forthcoming Reply with quote

Right now, the issue at hand is actually several small discrete problems:

- Module initalization ordering within Mango
- Factory creation for mango objects
- GC Hooking..?
- Build Tools
- Phobos

Exclamation Module Ordering
Nothing much new here. DMD has a flaw (IMO) that keeps modules w/o static ctors out of the module init sequence. The problem is that such modules can contain code that is both callable and calls code in other initalized modules. Mango gets torn to pieces in certan build configurations because of this. The workarounds are simple, but really only add clutter and useless code (e.g. "static this(){}") to something that really should be okay as-is.

Exclamation Factory Creation and Plugins:
The new parser is complete, and I'm working on the above features to allow DSP to be more or less pluggable with an existing server design. The idea is to put the entire library into a .dll that creates needed elements via factory creation. This way, I can concentrate on DSP itself and forget about (for the most part) all the different flavors that mango can take on when composed as a web server. At the same time, one can use DSP without having to know the entire source tree.

Personally I find this to be a key feature to not only DSP's utility but its future as a potential Apache plugin as well. I also hope that the typelibrary interface will be useful for mango itself.

Exclamation GC Hooking:
The GC hooking bit is really more experimental and not completely required. With a limited amount of hacking with Phobos, I am able to pass the collector to a custom .dll and have all object creations tracked on one collector. The problem is that the .dll is still running against code compiled in rather than code associated with the hooked collector. At the very least this is bad because objects still get thrown into two separate heaps; this causes things to go bonkers during a GC phase. The GC will need to be refactored into something more hookable if this is to be the way forward.

Exclamation Build Tool:
The similarities between Blacksmithing and Programming have always astonished me. A good blacksmith's shop usually has one peculiar trait: and endless array of tongs, most of which were made in that very same shop. Its also a good way to gauge how long the shop has been in operation, or at least how long the head smith has been at it! This is not unlike software engineering where the most mature technologies have the widest array of tools to manage what is ultimately intangible.

As D progresses, we are going to want to do more and more discrete things, and will need software to support that. Code beautifiers, doc generators, IDE's, Unittest suites, debuggers and build tools all fall out of this phenomenon. It is an inevidable and direct effect of a developing and maturing technology. The result is always host of satellite programs that are beautiful examples of how necessity drives invention.

Just last night I cobbled together a build tool inspired by the one provided with DIG plus a few comments on the DNG. I really liked the idea of using custom pragmas in D code to eliminate makefiles altogether.

I now have a parser that can fully parse and understand D import, version, debug and pragma statements. The parser follows a file import tree from a single root file and will map the dependencies. The dependency map is then walked based on the versions defined from the start (Windows, Win32,release,debug,etc) and will navigate the versions based on that data. This way it fully emulates the d-compiler as it visits import statemnts, but we can now do smarter things like check dependencies and pull in required files to the command line for compilation.

Its mostly complete, as all it needs is to have the dmd-execution bits added in, which I'll probably borrow from DSP. Overall its been a fun project as I wanted to see if I could compose a build tool from scratch. I'm even close to my line number target of 1000. Smile

A really nifty feature fell out of my debug output when I was halfway through development. It can generate an intermediate file that contains just the pragmas, imports, versions and debug branches (basically a dump of the dependency tree in D syntax). Since the intermediate file is still valid D, it can be fed back into the build tool to build the same target in a fraction of the time. Twisted Evil

Exclamation About Phobos:
Beeing on the steering comittee for Ares has opened my eyes to the fact that the D community has hit a milestone. As I see it: the overall feeling is that in order for D to move forward, more quality attention needs to be paid to the core DMD distribution itself. This is especially true for phobos, which is where Ares comes in. If the project can start working contributions into a namespace, then we will be in for some very good things.

In the meantime, DSP will be built against Mango as its 'platform' until the need to change arises.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Wed Sep 22, 2004 7:40 pm    Post subject: Update Reply with quote

With regards to the build tool, scratch the bit I said about generating an intermediate script.

The problem is more complicated than I first thought because of idosyncracies in how a given d file might be traversed. Apparently, I made too many assumptions in how imports and versions are used in combination.

In order to generate such an intermediate file, one would have to map all the possible routes into and out of all the imports in a given application. It's not possible to do when you ignore all the version statements as there may well be duplicate includes or circular references when traversed in that manner.

In other words, the only way to traverse a set of .d files is to behave just like the compiler and follow them one at a time. The difference here is that the build tool will keep track of what files its traversed and will only compile changed targets (much like make).

Also, I'm happy to say that the module ordering has been resolved as of DMD 0.102.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DSP All times are GMT - 6 Hours
Page 1 of 1

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