I think we should revert that change I made then but it would be nice to get it to compile on windows ;-)
I'm still not happy with Composite constructor passing it's this pointer to it's parent ComponentType. Is this not wrong? Is it saying I am a Composite and I am contained in myself?? In this case is the ComponentType contained in the composite? I think not so instead of passing "this" to ComponentType constructor maybe "0" would be more appropriate? Am I making sense? Cheers, On 06/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote: > Pete Robbins wrote: >> Yes it does help! I need to go and read the Assembly spec again ;0) >> >> But for now I think the change I put in is fine. >> >> Cheers, >> > > Pete, > > I thought that your change was OK too, but I just rebuilt everything > after updating from SVN and unfortunately this change breaks the Ruby > extension. Sorry I should have detected this before... but line 75 of > RubyImplementation.cpp needs the root directory of the composite to > find the Ruby script, as most people will specify a path to the script > file relative to the .composite file in <implementation.ruby > script="..."/>. > > The Ruby extension hits what I was trying to describe earlier in this > thread. Implementation artifacts are packaged with the composite, so > they need to know which composite they are packaged in, the current > directory etc. The Python and PHP extensions probably do not run into > this because they don't look at the script until the first invoke (and > are passed the composite at that point), but they will run into this > as soon as they try to read and introspect a script earlier in the > load sequence. > > So right now the Ruby extension is broken by this change. To build on > Linux without it, use configure --enable-ruby=no. > Pete, I tried to find a work around for this problem - so that you wouldn't have to revert some of these changes :) and avoid loading the script up-front, but then realized that I really need to, to introspect it and derive the services and references that will be presented to the other components in the composite for wiring for example. This is way before the first invocation comes or the first ServiceWrapper gets created. Also we can have multiple ServiceWrappers for a single Implementation object and we should load the script only once per Implementation, so I'll recommend that the Python and PHP extension load their scripts as well in the Implementation instead of the ServiceWrapper (but this can wait, we don't need to change that right now). So I don't see any easy way around this... If the other people are OK with that I can live without the Ruby extension for some time until you get to it or we find another solution, but I'm afraid we're going to have to put this Composite* back... Thanks, -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Pete
