CEDET

Hi,

consider the following:

---------------------
class testclass {
public:
  struct someStruct {int a; int b;};
  someStruct aVar;
  //  [.... constructor/other stuff ...]
  someStruct getVar() { return aVar; }
};

void f()
{
  testclass c;
  c.getVar().// <-- complete here
}
---------------------

Completion won't work because Semantic cannot find 'someStruct'. It can
only find it if you explicitly use testclass::someStruct.

The problem is in semantic-analyze-find-tag-sequence-default, where the
line

(semantic-analyze-tag-type tmp scope)

won't find the return type of getVar in 'scope'. A similar problem
exists when you have meta-tags like typedefs which refer to such locally
scoped types. But here the problem is in
semantic-analyze-dereference-metatype-1 with the line

(semantic-scope-find (semantic-tag-name ans) 'type scope)))

Also, you cannot find those types in the typecache, since you'd still
need the fully qualified name.

I'm not sure how this should be tackled. Any hints?

Best,
-David

Re: [CEDET-devel] return values with locally scoped types From: Eric M. Ludlam <eric@si...> - 2011-03-30 23:17 On 03/30/2011 05:53 PM, David Engster wrote: > Hi, > > consider the following: > > --------------------- > class testclass { > public: > struct someStruct {int a; int b;}; > someStruct aVar; > // [.... constructor/other stuff ...] > someStruct getVar() { return aVar; } > }; > > void f() > { > testclass c; > c.getVar().//<-- complete here > } > --------------------- > > Completion won't work because Semantic cannot find 'someStruct'. It can > only find it if you explicitly use testclass::someStruct. > > The problem is in semantic-analyze-find-tag-sequence-default, where the > line > > (semantic-analyze-tag-type tmp scope) > > won't find the return type of getVar in 'scope'. A similar problem > exists when you have meta-tags like typedefs which refer to such locally > scoped types. But here the problem is in > semantic-analyze-dereference-metatype-1 with the line > > (semantic-scope-find (semantic-tag-name ans) 'type scope))) > > Also, you cannot find those types in the typecache, since you'd still > need the fully qualified name. > > I'm not sure how this should be tackled. Any hints? Hi David, This can probably be solved using the scope input. Note that in semantic-analyze-find-tag-sequence-default around line 306 there is a mini-scope being calculated. I'd guess around line 316 (the line you quote) we'd need to add something similar, where the tag we just found (tmp == getVar in this case) came from somewhere, and a new scope should be generated from that location. Perhaps a call to semantic-tag-calculate-parent can get a datatype from which a miniscope can be generated? Eric

Re: [CEDET-devel] return values with locally scoped types From: David Engster <deng@ra...> - 2011-05-19 16:19 Eric M. Ludlam writes: > On 03/30/2011 05:53 PM, David Engster wrote: >> Hi, >> >> consider the following: > >> >> --------------------- >> class testclass { >> public: >> struct someStruct {int a; int b;}; >> someStruct aVar; >> // [.... constructor/other stuff ...] >> someStruct getVar() { return aVar; } >> }; >> >> void f() >> { >> testclass c; >> c.getVar().//<-- complete here >> } >> --------------------- >> >> Completion won't work because Semantic cannot find 'someStruct'. It can >> only find it if you explicitly use testclass::someStruct. >> >> The problem is in semantic-analyze-find-tag-sequence-default, where the >> line >> >> (semantic-analyze-tag-type tmp scope) >> >> won't find the return type of getVar in 'scope'. A similar problem >> exists when you have meta-tags like typedefs which refer to such locally >> scoped types. But here the problem is in >> semantic-analyze-dereference-metatype-1 with the line >> >> (semantic-scope-find (semantic-tag-name ans) 'type scope))) >> >> Also, you cannot find those types in the typecache, since you'd still >> need the fully qualified name. >> >> I'm not sure how this should be tackled. Any hints? > > Hi David, > > This can probably be solved using the scope input. Note that in > semantic-analyze-find-tag-sequence-default around line 306 there is a > mini-scope being calculated. I'd guess around line 316 (the line you > quote) we'd need to add something similar, where the tag we just found > (tmp == getVar in this case) came from somewhere, and a new scope should > be generated from that location. Perhaps a call to > semantic-tag-calculate-parent can get a datatype from which a miniscope > can be generated? It's been a while, but I've been using this patch in my local branch for the past weeks without problems: === modified file 'semantic/semantic-analyze.el' --- semantic/semantic-analyze.el 2010-04-18 21:45:44 +0000 +++ semantic/semantic-analyze.el 2011-05-19 13:14:41 +0000 @@ -313,7 +313,15 @@ (or (semantic-analyze-type tmp miniscope) tmp)) (t - (semantic-analyze-tag-type tmp scope)))) + (when miniscope + (let ((rawscope + (semantic-tag-type-members + (semantic-tag-calculate-parent tmp)))) + (when rawscope + (oset miniscope fullscope + (append (oref miniscope fullscope) + rawscope))))) + (semantic-analyze-tag-type tmp miniscope)))) (typefile (when tmptype (semantic-tag-file-name tmptype))) Unit tests run fine with it. Here's also the above test case: === modified file 'semantic/tests/testdoublens.cpp' --- semantic/tests/testdoublens.cpp 2010-09-24 01:53:43 +0000 +++ semantic/tests/testdoublens.cpp 2011-05-19 13:12:45 +0000 @@ -158,3 +158,20 @@ } // namespace f } // namespace d + +// Complete member structures +// David Engster, 2011 + +class testclass { +public: + struct someStruct {int myFoo; int myBar;}; + someStruct aVar; + someStruct getVar() { return aVar; } +}; + +void f() +{ + testclass c; + c.getVar(). // -9- + ; //#9# ( "myFoo" "myBar" ) +} Should I check this into trunk? -David

Re: [CEDET-devel] return values with locally scoped types From: Eric M. Ludlam <eric@si...> - 2011-05-20 00:06 On 05/19/2011 12:18 PM, David Engster wrote: > Eric M. Ludlam writes: >> On 03/30/2011 05:53 PM, David Engster wrote: >>> Hi, >>> >>> consider the following: >> >>> >>> --------------------- >>> class testclass { >>> public: >>> struct someStruct {int a; int b;}; >>> someStruct aVar; >>> // [.... constructor/other stuff ...] >>> someStruct getVar() { return aVar; } >>> }; >>> >>> void f() >>> { >>> testclass c; >>> c.getVar().//<-- complete here >>> } >>> --------------------- >>> >>> Completion won't work because Semantic cannot find 'someStruct'. It can >>> only find it if you explicitly use testclass::someStruct. >>> >>> The problem is in semantic-analyze-find-tag-sequence-default, where the >>> line >>> >>> (semantic-analyze-tag-type tmp scope) >>> >>> won't find the return type of getVar in 'scope'. A similar problem >>> exists when you have meta-tags like typedefs which refer to such locally >>> scoped types. But here the problem is in >>> semantic-analyze-dereference-metatype-1 with the line >>> >>> (semantic-scope-find (semantic-tag-name ans) 'type scope))) >>> >>> Also, you cannot find those types in the typecache, since you'd still >>> need the fully qualified name. >>> >>> I'm not sure how this should be tackled. Any hints? >> >> Hi David, >> >> This can probably be solved using the scope input. Note that in >> semantic-analyze-find-tag-sequence-default around line 306 there is a >> mini-scope being calculated. I'd guess around line 316 (the line you >> quote) we'd need to add something similar, where the tag we just found >> (tmp == getVar in this case) came from somewhere, and a new scope should >> be generated from that location. Perhaps a call to >> semantic-tag-calculate-parent can get a datatype from which a miniscope >> can be generated? > > It's been a while, but I've been using this patch in my local branch for > the past weeks without problems: > That looks exactly like what I expected. This would be great to check in. With a bonus test too. Huzzah! Thanks Eric

Re: [CEDET-devel] return values with locally scoped types From: David Engster <deng@ra...> - 2011-05-23 18:05 Eric M. Ludlam writes: > That looks exactly like what I expected. This would be great to check > in. With a bonus test too. Huzzah! Well, I've changed my mind. :-) I'm afraid just including the parent into the scope is not enough. Consider the following example: ------------------------------------------- namespace foo { struct myStruct {int foo1; int foo2;}; class MyClass { public: myStruct bla; }; } void func() { foo::MyClass c; c.bla. // Complete here } ------------------------------------------- 'myStruct' is member of the namespace 'foo', but not of 'MyClass'. And now, just for fun, let's throw a template and typedef into the mix: --------------------------------------- namespace foo { template<typename _T> struct myStruct {_T foo1; _T foo2;}; template<typename T> class MyClass { public: typedef myStruct<T> myType; myType bla; }; } void func() { foo::MyClass<int> c; c.bla. // Complete here } -------------------------------------- While Semantic does find 'foo1/2', it assumes those are of type 'T'. This is because the dereferencer doesn't get the chance to dereference the template and the typedef at the same time; it will first dereference the template for MyClass when dealing with 'c', and it will then separately deal with the typedef when looking at 'bla'. However, there it will only see 'MyClass<T>' as the parent and not 'MyClass<myStruct>', which obviously doesn't exist anywhere in written form. Here's a snippet which should deal with both: --- trunk/semantic/semantic-analyze.el 2011-03-09 12:09:43.000000000 +0100 +++ poly-template/semantic/semantic-analyze.el 2011-05-23 17:43:27.000000000 +0200 @@ -341,6 +341,21 @@ (when (and fname (semantic-tag-p tmp) (not (semantic-tag-in-buffer-p tmp))) (semantic--tag-put-property tmp :filename fname)) + + (when (and tmp (semantic-tag-p tmp)) + (let ((tagscope + (save-excursion + (semantic-go-to-tag tmp) + (semantic-calculate-scope))) + (rawscope + (semantic-tag-type-members tmptype) + )) + (when tagscope + (oset scope fullscope + (append rawscope + (oref tagscope fullscope) + (oref scope fullscope)))))) + (setq tag (cons tmp tag)) (setq tagtype (cons tmptype tagtype)) ) In words: - Calculate a local scope for 'tmp' (which in the first example is 'foo::MyClass::bla') and include it into scope. - Include all the type members of the type we're currently dealing with (in the second example those are the members of the dereferenced 'MyClass<int>'). It's also important that those members are at the front of the scope list. I haven't tested this fully; I'm also not sure how this will affect speed (how expensive is `semantic-calculate-scope'?). I probably will have to benchmark this. But maybe you have a better idea? BTW, it might be that the second example doesn't work at all with trunk. I'm working with my local branch, which already has a ton of changes to better deal with templates... -David

Re: [CEDET-devel] return values with locally scoped types From: Eric M. Ludlam <eric@si...> - 2011-05-27 01:46 Hi David, Interesting new issues. To figure out performance, just put the cursor on some example, and do: M-x semantic-elp-analyze RET I would guess your code won't do much if the local context doesn't have the case where this extra work is needed?? That would be the best solution as a little performance issue is fine for more complex problems. Eric On 05/23/2011 02:04 PM, David Engster wrote: > Eric M. Ludlam writes: >> That looks exactly like what I expected. This would be great to check >> in. With a bonus test too. Huzzah! > > Well, I've changed my mind. :-) > > I'm afraid just including the parent into the scope is not > enough. Consider the following example: > > ------------------------------------------- > namespace foo { > struct myStruct {int foo1; int foo2;}; > > class MyClass > { > public: > myStruct bla; > }; > } > > void func() > { > foo::MyClass c; > c.bla. // Complete here > } > ------------------------------------------- > > 'myStruct' is member of the namespace 'foo', but not of 'MyClass'. And > now, just for fun, let's throw a template and typedef into the mix: > > --------------------------------------- > namespace foo { > > template<typename _T> > struct myStruct {_T foo1; _T foo2;}; > > template<typename T> > class MyClass > { > public: > typedef myStruct<T> myType; > myType bla; > }; > } > > void func() > { > foo::MyClass<int> c; > c.bla. // Complete here > } > -------------------------------------- > > While Semantic does find 'foo1/2', it assumes those are of type > 'T'. This is because the dereferencer doesn't get the chance to > dereference the template and the typedef at the same time; it will first > dereference the template for MyClass when dealing with 'c', and it will > then separately deal with the typedef when looking at 'bla'. However, > there it will only see 'MyClass<T>' as the parent and not > 'MyClass<myStruct>', which obviously doesn't exist anywhere in written > form. > > Here's a snippet which should deal with both: > > --- trunk/semantic/semantic-analyze.el 2011-03-09 12:09:43.000000000 +0100 > +++ poly-template/semantic/semantic-analyze.el 2011-05-23 17:43:27.000000000 +0200 > @@ -341,6 +341,21 @@ > (when (and fname (semantic-tag-p tmp) > (not (semantic-tag-in-buffer-p tmp))) > (semantic--tag-put-property tmp :filename fname)) > + > + (when (and tmp (semantic-tag-p tmp)) > + (let ((tagscope > + (save-excursion > + (semantic-go-to-tag tmp) > + (semantic-calculate-scope))) > + (rawscope > + (semantic-tag-type-members tmptype) > + )) > + (when tagscope > + (oset scope fullscope > + (append rawscope > + (oref tagscope fullscope) > + (oref scope fullscope)))))) > + > (setq tag (cons tmp tag)) > (setq tagtype (cons tmptype tagtype)) > ) > > > In words: > > - Calculate a local scope for 'tmp' (which in the first example is > 'foo::MyClass::bla') and include it into scope. > > - Include all the type members of the type we're currently dealing > with (in the second example those are the members of the > dereferenced 'MyClass<int>'). It's also important that those members > are at the front of the scope list. > > I haven't tested this fully; I'm also not sure how this will affect > speed (how expensive is `semantic-calculate-scope'?). I probably will > have to benchmark this. But maybe you have a better idea? > > BTW, it might be that the second example doesn't work at all with > trunk. I'm working with my local branch, which already has a ton of > changes to better deal with templates... > > -David > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel >

Re: [CEDET-devel] return values with locally scoped types From: David Engster <deng@ra...> - 2011-06-03 16:53 Eric M. Ludlam writes: > Hi David, > > Interesting new issues. To figure out performance, just put the cursor > on some example, and do: > > M-x semantic-elp-analyze RET Problem is that one completion takes ~0.1s, which is not long enough to give a significant measure. Instead, I used the whole semantic-ia-utest suite; `semantic-analyze-find-tag-sequence' is called 115 times there. Turns out, my addition of one semantic-calculate-scope did make the unit test about 7% slower. While this isn't terrible and it mainly affects completion, I still didn't like it, especially because most of the time is done in the search for local variables, which I figure is only necessary for very special cases (which I will surely stumble upon, but not today). So instead of a full scope calculation, I only look for the parents and their scope, and include it for the next iteration: *** semantic/semantic-analyze.el 2010-04-18 21:45:44 +0000 --- semantic/semantic-analyze.el 2011-06-03 15:06:33 +0000 *************** *** 341,346 **** --- 341,367 ---- (when (and fname (semantic-tag-p tmp) (not (semantic-tag-in-buffer-p tmp))) (semantic--tag-put-property tmp :filename fname)) + + (when (and (cdr s) + tmp + (semantic-tag-p tmp)) + (save-excursion + (semantic-go-to-tag tmp) + (let ((parents (semantic-analyze-scope-nested-tags (point) nil)) + (newscope (semantic-scope-cache "miniscope")) + parentscope rawscope) + (when parents + (oset newscope parents parents) + (setq parentscope + (semantic-analyze-scoped-tags nil newscope))) + (setq rawscope + (semantic-tag-type-members tmptype)) + (when (or parentscope rawscope) + (oset scope fullscope + (append rawscope + parentscope + (oref scope fullscope))))))) + (setq tag (cons tmp tag)) (setq tagtype (cons tmptype tagtype)) ) This also makes the code slower, but just a tiny bit. Here's one sample: Old code: semantic-ia-utest 1 8.111613 8.111613 semantic-parse-region 793 3.4006790000 0.0042883720 semantic-parse-region-default 793 3.3928430000 0.0042784905 semantic-calculate-scope 135 3.361651 0.0249011185 semantic-parse-region-c-mode 679 3.1108660000 0.0045815405 semantic-analyze-current-context 88 3.0281379999 0.0344106590 semantic-ia-utest-buffer 12 3.0275339999 0.2522945 semantic-analyze-current-context-default 88 3.0237289999 0.0343605568 semantic-repeat-parse-whole-stream 793 2.6946140000 0.0033980000 semantic-parse-stream 5511 2.4156130000 0.0004383257 semantic-parse-stream-default 5370 2.3667209999 0.0004407301 semantic-bovinate-stream 5370 2.3538729999 0.0004383376 semantic-fetch-tags 1436 2.3070329999 0.0016065689 New code: semantic-ia-utest 1 8.162042 8.162042 semantic-parse-region 793 3.4838440000 0.0043932459 semantic-parse-region-default 793 3.3902579999 0.0042752307 semantic-calculate-scope 135 3.3376609999 0.0247234148 semantic-parse-region-c-mode 679 3.1951430000 0.0047056597 semantic-ia-utest-buffer 12 3.071324 0.2559436666 semantic-analyze-current-context 88 3.0705029999 0.0348920795 semantic-analyze-current-context-default 88 3.0660609999 0.0348416022 semantic-repeat-parse-whole-stream 793 2.6827439999 0.0033830315 semantic-parse-stream 5511 2.5633560000 0.0004651344 semantic-parse-stream-default 5370 2.4686579999 0.0004597128 semantic-bovinate-stream 5370 2.4563239999 0.0004574160 semantic-fetch-tags 1452 2.3299349999 0.0016046384 You see the difference consists mainly of 16 additional calls to semantic-fetch-tags for 115 calls to semantic-analyze-find-tag-sequence. > I would guess your code won't do much if the local context doesn't have > the case where this extra work is needed?? That would be the best > solution as a little performance issue is fine for more complex problems. Well, you usually define your structures and classes outside the local scope, so this is actually a very common thing. And unfortunately, we cannot know if it is really necessary until we've done it... I could implement this as a fallback if `semantic-analyze-tag-type' doesn't return anything, but I think this somewhat ugly, and in practical situations this may even be slower, since failing completions are pretty common and we'll then do double work. -David

Re: [CEDET-devel] return values with locally scoped types From: Eric M. Ludlam <ericludlam@gm...> - 2011-06-14 11:18 Hi David, Sorry for my slow reply. I switched service providers and it has taken a while to get my email up and running again reliably. (This email is, in fact, a test too.) Anyway, thanks for the analysis below. Your new solution seems fine to me also, and a good thing to include. As the number of 'mini scopes' calculated grows, I wonder if it is time to consider increasing the number of caches of scopes. Right now there is one scope per semanticdb, and it gets reset as the cursor moves between tags. Perhaps scopes for parents, or multiple scopes per file can also be cached somewhere to help with this case if a full cache calculation proves necessary in the future. Eric On 06/03/2011 12:52 PM, David Engster wrote: > Eric M. Ludlam writes: >> Hi David, >> >> Interesting new issues. To figure out performance, just put the cursor >> on some example, and do: >> >> M-x semantic-elp-analyze RET > > Problem is that one completion takes ~0.1s, which is not long enough to > give a significant measure. Instead, I used the whole semantic-ia-utest > suite; `semantic-analyze-find-tag-sequence' is called 115 times there. > > Turns out, my addition of one semantic-calculate-scope did make the unit > test about 7% slower. While this isn't terrible and it mainly affects > completion, I still didn't like it, especially because most of the time > is done in the search for local variables, which I figure is only > necessary for very special cases (which I will surely stumble upon, but > not today). > > So instead of a full scope calculation, I only look for the parents and > their scope, and include it for the next iteration: > > *** semantic/semantic-analyze.el 2010-04-18 21:45:44 +0000 > --- semantic/semantic-analyze.el 2011-06-03 15:06:33 +0000 > *************** > *** 341,346 **** > --- 341,367 ---- > (when (and fname (semantic-tag-p tmp) > (not (semantic-tag-in-buffer-p tmp))) > (semantic--tag-put-property tmp :filename fname)) > + > + (when (and (cdr s) > + tmp > + (semantic-tag-p tmp)) > + (save-excursion > + (semantic-go-to-tag tmp) > + (let ((parents (semantic-analyze-scope-nested-tags (point) nil)) > + (newscope (semantic-scope-cache "miniscope")) > + parentscope rawscope) > + (when parents > + (oset newscope parents parents) > + (setq parentscope > + (semantic-analyze-scoped-tags nil newscope))) > + (setq rawscope > + (semantic-tag-type-members tmptype)) > + (when (or parentscope rawscope) > + (oset scope fullscope > + (append rawscope > + parentscope > + (oref scope fullscope))))))) > + > (setq tag (cons tmp tag)) > (setq tagtype (cons tmptype tagtype)) > ) > > > This also makes the code slower, but just a tiny bit. Here's one sample: > > Old code: > > semantic-ia-utest 1 8.111613 8.111613 > semantic-parse-region 793 3.4006790000 0.0042883720 > semantic-parse-region-default 793 3.3928430000 0.0042784905 > semantic-calculate-scope 135 3.361651 0.0249011185 > semantic-parse-region-c-mode 679 3.1108660000 0.0045815405 > semantic-analyze-current-context 88 3.0281379999 0.0344106590 > semantic-ia-utest-buffer 12 3.0275339999 0.2522945 > semantic-analyze-current-context-default 88 3.0237289999 0.0343605568 > semantic-repeat-parse-whole-stream 793 2.6946140000 0.0033980000 > semantic-parse-stream 5511 2.4156130000 0.0004383257 > semantic-parse-stream-default 5370 2.3667209999 0.0004407301 > semantic-bovinate-stream 5370 2.3538729999 0.0004383376 > semantic-fetch-tags 1436 2.3070329999 0.0016065689 > > New code: > > semantic-ia-utest 1 8.162042 8.162042 > semantic-parse-region 793 3.4838440000 0.0043932459 > semantic-parse-region-default 793 3.3902579999 0.0042752307 > semantic-calculate-scope 135 3.3376609999 0.0247234148 > semantic-parse-region-c-mode 679 3.1951430000 0.0047056597 > semantic-ia-utest-buffer 12 3.071324 0.2559436666 > semantic-analyze-current-context 88 3.0705029999 0.0348920795 > semantic-analyze-current-context-default 88 3.0660609999 0.0348416022 > semantic-repeat-parse-whole-stream 793 2.6827439999 0.0033830315 > semantic-parse-stream 5511 2.5633560000 0.0004651344 > semantic-parse-stream-default 5370 2.4686579999 0.0004597128 > semantic-bovinate-stream 5370 2.4563239999 0.0004574160 > semantic-fetch-tags 1452 2.3299349999 0.0016046384 > > > You see the difference consists mainly of 16 additional calls to > semantic-fetch-tags for 115 calls to semantic-analyze-find-tag-sequence. > >> I would guess your code won't do much if the local context doesn't have >> the case where this extra work is needed?? That would be the best >> solution as a little performance issue is fine for more complex problems. > > Well, you usually define your structures and classes outside the local > scope, so this is actually a very common thing. And unfortunately, we > cannot know if it is really necessary until we've done it... > > I could implement this as a fallback if `semantic-analyze-tag-type' > doesn't return anything, but I think this somewhat ugly, and in > practical situations this may even be slower, since failing completions > are pretty common and we'll then do double work. > > -David > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel >

Re: [CEDET-devel] return values with locally scoped types From: David Engster <deng@ra...> - 2011-06-14 21:15 Eric M. Ludlam writes: > Anyway, thanks for the analysis below. Your new solution seems fine to > me also, and a good thing to include. OK, I will check this in. > As the number of 'mini scopes' calculated grows, I wonder if it is time > to consider increasing the number of caches of scopes. Right now there > is one scope per semanticdb, and it gets reset as the cursor moves > between tags. > > Perhaps scopes for parents, or multiple scopes per file can also be > cached somewhere to help with this case if a full cache calculation > proves necessary in the future. Maybe this will become necessary, but at the moment I don't think the scope calculation is critical. It might become critical for applications like refactoring, where lots of scope calculations are needed, but those aren't written yet... ;-) -David

1 message has been excluded from this view by a project administrator.