[aspectc-user] Compiler Error - Related Error being fixed in (Version 1.0pre1: 10/2005)?
John C. Weicher
jweicher at piocon.com
Thu Oct 20 18:38:51 CEST 2005
Olaf-
Ha ha ha, please don't think me ungrateful, but I'd rather not say.
There's some competition on the task, and I'd like to keep our doings to
ourselves until we're ready to release. It's always nice to be the first,
you know? As for AspectC++, it's been absolutely great. Up until recently
our approach was direct modification of existing functions, hacking up the
original application's source files, etc. Okay for experimentation, but
totally unacceptable in the end as a means of producing an external,
optional patch-like modification, you know? Then we discovered aspects, and
it's been great. So definitely thank you for all your work. I'll keep you
posted if you're interested!
-John
> -----Original Message-----
> From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
> Sent: Thursday, October 20, 2005 11:27 AM
> To: John C. Weicher
> Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed in
> (Version 1.0pre1: 10/2005)?
>
> John,
>
> on which open source project are you working? How much trouble did you
> have with AspectC++ so far? ;-)
>
> Olaf
>
>
> Olaf Spinczyk wrote:
> > Hi,
> >
> > for SystemC there is no solution, yet. We hope simply that no user needs
> > execution advice for the sc_main function ;-), which is similar to
> > main() in normaly C++ code.
> >
> > The best solution would be a last minute fix that is integrated into
> > version 1.0pre1. I'll do what I can.
> >
> > Olaf
> >
> > John C. Weicher wrote:
> >> Olaf-
> >> Dead on! That is exactly the situation. And I discovered that
> >> late last
> >> night. If I manually go in and add the declaration before the
> >> definition,
> >> it compiles perfectly (the extern header file issue never occurred to
> me
> >> though). Do you have any suggestions on a way to get around this
> without
> >> the manual intervention? Because everything being open source, it
> >> would be
> >> nice to not make potential users who wanted to rebuild the app I'm
> >> modifying
> >> on their own, have to go in and do the same. Right now the beauty is
> >> that
> >> everything is done by a single additional script that I would
> distribute
> >> with my modification/patch. They'd just have to drop in the
> >> distribution,
> >> the scripts calls the aspect compiler to make the changes, calls the
> apps
> >> original make routines they would have had to call anyway, and bingo,
> >> they've modified their app. I'd love to be able to keep it that way.
> >>
> >> If this is not doable, I'll just have to come up with another
> >> strategy. I'm
> >> sorry I've taken so much of your time on this issue already, as I know
> >> now
> >> it's kind of in my court. But you mentioned another similar encounter,
> >> SystemC? What was the solution in that case?
> >>
> >> I really appreciate the help already given.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
> >>> Sent: Thursday, October 20, 2005 11:00 AM
> >>> To: John C. Weicher
> >>> Cc: aspectc-user at aspectc.org
> >>> Subject: Re: [aspectc-user] Compiler Error - Related Error being
> >>> fixed in
> >>> (Version 1.0pre1: 10/2005)?
> >>>
> >>> Hi,
> >>>
> >>> I'm slowly beginning to understand (at least I hope so) ...
> >>>
> >>> * you are using ac++ in the WPT mode and not via ag++
> >>> * your command line options are "-p module/dev -d module"
> >>> * the "include" directory tree does not belong to the project
> >>> (from ac++'s point of view)
> >>> * the function for which you define execution advice is
> >>> *declared* somewhere in "include", but defined in your
> >>> part, i.e. module
> >>>
> >>> Is that right? It explains the behavior completely:
> >>>
> >>> * call advice works properly, as the location of the call is part
> >>> of the ac++ project
> >>>
> >>> * execution advice does not work completely, because there is a
> function
> >>> declaration that does not belong to the ac++ project
> >>>
> >>> We have a similar problem with the SystemC library. In this case the
> >>> function sc_main is declared in a library header file, but the
> >>> implementation has to be provided in the application code.
> >>>
> >>> o check if we are right, you can insert a declaration of the function
> in
> >>> front of the definition. Then the execution advice should work as
> >>> expected.
> >>>
> >>> Does that help?
> >>>
> >>> Olaf
> >>>
> >>>
> >>> John C. Weicher wrote:
> >>>> Olaf-
> >>>> As a matter of fact, yes, the prototype for the function that I am
> >>>> attempting to call around is included in a header file that is
> outside
> >>> of my
> >>>> project directory. I am using aspects to increase the functionality
> of
> >>> one
> >>>> module in a much larger open source application. So like many such
> >>>> applications, the source code that I am extending is in a separate
> part
> >>> of
> >>>> the directory tree than the application's main include directory,
> >>> containing
> >>>> the headers for those sources:
> >>>>
> >>>> AppRoot
> >>>> |
> >>>> -- include <- prototype for function I'm wrapping in header file
> here
> >>>> | (It's an existing application function that I'm
> >>>> wrapping,
> >>>> | not one of my own that I can easily relocate)
> >>>> |
> >>>> -- module <- where I am placing weaved code to be placed so it can
> >>> still
> >>>> | be found by application's existing make routines, etc.
> >>>> |
> >>>> -- dev <- new directory I've created where I've copied and keep
> >>>> original versions of source and aspects
> >>>>
> >>>> The problem is that this is a large application, to which I am
> >>>> trying to
> >>>> develop a useful extension to that I could offer to people. I'm only
> >>>> mentioning all this because the point is I want to keep my
> >>>> modifications
> >>>> through aspects as modularized from the rest of code as possible (so
> it
> >>> can
> >>>> be easily applied by interested parties). I want to avoid having to
> >>> make
> >>>> changes to files outside of that one 'module' directory (and more
> >>>> specifically the 'dev') directory. If possible, I want to avoid
> having
> >>> to
> >>>> make changes to outside files, for example those in the apps main
> >>> include
> >>>> directory. For this same reason, I don't want to rename any function
> >>> names
> >>>> as the function I am wrapping is actually called from a whole
> different
> >>>> module, which means I'd have to edit IT'S code as well, etc.
> >>>>
> >>>> I assume this is causing my problem, because there is then an
> existing
> >>>> prototype for the function that I am wrapping, which is a point you
> >>> asked
> >>>> about at the end of your last post.
> >>>>
> >>>> Is it possible to force ac++ to add any necessary new prototypes
> right
> >>> into
> >>>> the file that contains the source for functions it is
> >>>> weaving/modifying?
> >>>>
> >>>> Thanks again for your help.
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-
> erlangen.de]
> >>>>> Sent: Thursday, October 20, 2005 3:16 AM
> >>>>> To: John C. Weicher
> >>>>> Cc: aspectc-user at aspectc.org
> >>>>> Subject: Re: [aspectc-user] Compiler Error - Related Error being
> fixed
> >>> in
> >>>>> (Version 1.0pre1: 10/2005)?
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> there should be no problem, even if the called function (F1 in your
> >>>>> example) is part of a separate library. The call advice only
> >>>>> affects the
> >>>>> function that calls (F2). You can test it with this example:
> >>>>>
> >>>>> void f2 () {
> >>>>> puts ("hello");
> >>>>> }
> >>>>>
> >>>>> int main () {
> >>>>> f2 ();
> >>>>> }
> >>>>>
> >>>>> aspect Foo {
> >>>>> advice execution("% f2(...)") : before() {
> >>>>> printf ("before\n");
> >>>>> }
> >>>>> advice call("% puts(...)") && within("% f2(...)") : around() {
> >>>>> tjp->proceed ();
> >>>>> printf ("after\n");
> >>>>> }
> >>>>> };
> >>>>>
> >>>>> The libc function puts is definitely part of a separate library.
> >>>>>
> >>>>> AspectC++ does not generate the function prototype that is missing
> in
> >>>>> your case, if
> >>>>>
> >>>>> (A) somewhere is a prototype declaration of the wrapped function
> (f2).
> >>>>> (in this case the wrapper function prototype will be generated in
> >>>>> front of this declaration and doesn't have to be generated in
> front
> >>>>> of the definition)
> >>>>>
> >>>>> (B) the wrapped function is a member function of a class
> >>>>> (in this case the function is either defined in a class body and,
> >>>>> thus, declarations are not necessary, or the function is defined
> >>>>> outside the class body. In this case there will be a declaration
> >>>>> within the class body and the declaration of the wrapper function
> >>>>> will be generated there)
> >>>>>
> >>>>> Is it possible that there is a declaration of the function f2 (the
> one
> >>>>> for which you defined execution advice) in some header file that is
> >>>>> *not* part of your project (-p option!)? Maybe it is the prototype
> >>>>> of a
> >>>>> different function that unintentionally has the same name. You
> >>>>> could try
> >>>>> to rename your function to rule out this possibility.
> >>>>>
> >>>>> - Olaf
> >>>>>
> >>>>>
> >>>>> John C. Weicher wrote:
> >>>>>> I apologize for not CC-ing my first response to the listserv as
> well,
> >>> so
> >>>>>> thank you for doing so with your last reply, so that message can at
> >>>>> least
> >>>>>> now be included.
> >>>>>>
> >>>>>> With that said, unfortunately, I am not sure how to give you a
> >>>>>> minimal
> >>>>> step
> >>>>>> by step, as when I do testing similar to yours, it works for me
> too!
> >>>>> But in
> >>>>>> doing so, I have found what I think is the source of the problem.
> >>> There
> >>>>> is
> >>>>>> in fact a prototype that is being omitted from the weaved code.
> >>>>>>
> >>>>>> Using the following example, all but identical to yours:
> >>>>>>
> >>>>>> void F1(){
> >>>>>> }
> >>>>>>
> >>>>>> void F2(){
> >>>>>> F1();
> >>>>>> }
> >>>>>>
> >>>>>> int main(int argc, char **argv){
> >>>>>> F2();
> >>>>>> return 0;
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> aspect intercept{
> >>>>>>
> >>>>>> advice call("% F1(...)") && within("% F2(...)") : around() {
> >>>>>> printf("About to enter F1()\n");
> >>>>>> tjp->proceed();
> >>>>>> }
> >>>>>>
> >>>>>> advice execution("% F2(...)") : before() {
> >>>>>> printf("About to enter F2\n");
> >>>>>> }
> >>>>>> };
> >>>>>> --
> >>>>>>
> >>>>>> Everything here works just fine. But when I go back and look at my
> >>>>> actual
> >>>>>> code, I notice a difference between it and the code generated for
> the
> >>>>> above
> >>>>>> test. In the above test, the modifications for the
> execution/before
> >>>>> advice
> >>>>>> are as follows:
> >>>>>>
> >>>>>> <snip>
> >>>>>> #line 7 "./main.c"
> >>>>>>
> >>>>>> #line 1 ""
> >>>>>>
> >>>>>> inline void __exec_old_F2();
> >>>>>>
> >>>>>> #line 7 "./main.c"
> >>>>>> void F2()
> >>>>>> #line 1 ""
> >>>>>> {
> >>>>>> AC::invoke_intercept_intercept_a1_before ();
> >>>>>> __exec_old_F2();
> >>>>>>
> >>>>>> }
> >>>>>> inline void __exec_old_F2()
> >>>>>> #line 7 "./main.c"
> >>>>>> {
> >>>>>> __call__ZN2F2Ev_0_0 ();
> >>>>>> }
> >>>>>> <snip>
> >>>>>>
> >>>>>> This makes perfect sense. We have the prototype for the inline
> >>>>>> altered
> >>>>>> original function, the replacement of the original function which
> >>>>>> calls
> >>>>> the
> >>>>>> inline alternate, and then the definition of the inline alternate
> >>> (which
> >>>>>> itself has internal modifications due to the other call/around
> advice
> >>>>> for
> >>>>>> the F1).
> >>>>>>
> >>>>>> The kicker is that in my real code, the general layout is the
> >>>>>> same, but
> >>>>> NO
> >>>>>> prototype is ever inserted above the replacement of the original
> >>>>> function.
> >>>>>> There is just the replacement of the original function which calls
> >>>>>> the
> >>>>>> inline alternate, and then the definition of the inline alternate.
> >>>>> Without
> >>>>>> the prototype above all this, the undeclared error is going to
> occur.
> >>>>>>
> >>>>>> As I said, other than the above program you gave me, I don't know
> how
> >>> to
> >>>>>> give you another minimal step by step. The layout of my real
> project
> >>> is
> >>>>>> identical. Can you think of any other reason why a prototype
> >>>>>> would be
> >>>>>> omitted?
> >>>>>>
> >>>>>> Actually I just realized that I have made a mistake. There is one
> >>>>>> difference. The function with the call/around advice (the nested
> >>>>> function)
> >>>>>> is NOT in the same file as the function causing problems with the
> >>>>> missing
> >>>>>> prototype. It's part of another library. I apologize I missed
> this.
> >>>>>> However, being call/around, the compiler never needs access to it's
> >>>>> actual
> >>>>>> code, correct?, and in fact I wasn't having any problems with it's
> >>>>>> call/around advice anyway, until I added the execute/before advice
> to
> >>>>> the
> >>>>>> function that calls IT.
> >>>>>>
> >>>>>> Phew! Sorry for the long post. Maybe this will change the
> >>>>>> situation?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: John C. Weicher [mailto:jweicher at piocon.com]
> >>>>>>> Sent: Wednesday, October 19, 2005 9:13 AM
> >>>>>>> To: 'Olaf Spinczyk'
> >>>>>>> Subject: RE: [aspectc-user] Compiler Error - Related Error being
> >>>>>>> fixed
> >>>>> in
> >>>>>>> (Version 1.0pre1: 10/2005)?
> >>>>>>>
> >>>>>>> Thanks for your help so far. There is really only one difference
> >>>>> between
> >>>>>>> my code and your test program. It's not really a situation of
> >>>>> around/call
> >>>>>>> and before/execution of the same function. Using your example,
> the
> >>>>>>> function having advice inserted before its execution is F2(), not
> >>> F1().
> >>>>> I
> >>>>>>> of course have no idea if this should make any difference?
> >>>>>>>
> >>>>>>> In other words, in your program you have a function F1 that is
> both
> >>>>> being
> >>>>>>> called around, as well as having code inserted before its
> execution
> >>>>>>> contents.
> >>>>>>>
> >>>>>>> In my code I have a function F1 that is being called around, and a
> >>>>>>> _different_ function (from which the first is called), that is
> >>>>>>> having
> >>>>> the
> >>>>>>> code inserted before it.
> >>>>>>>
> >>>>>>> I admit even to me this seems like a trivial difference, but you'd
> >>> know
> >>>>>>> far better. Could there be a problem with applying before advice
> >>>>>>> to a
> >>>>>>> function and then applying around advice to another function call
> >>> within
> >>>>>>> it? Perhaps simply in how it decides in which order to append
> weaved
> >>>>> code
> >>>>>>> to the source file? I am totally grasping at straws here.
> >>>>>>> Obviously
> >>>>> the
> >>>>>>> operations of the weaver are way over my head. It's just that
> >>>>>>> the odd
> >>>>>>> thing is, if I go look at the source file, all the code for all
> >>> advices
> >>>>> is
> >>>>>>> properly generated. It's just that the code for the alternate
> >>>>>>> call to
> >>>>> the
> >>>>>>> function to handle the before insertion is placed after it's
> >>> invocation,
> >>>>>>> giving the not defined error when parsed for compling.
> >>>>>>> Otherwise, all
> >>>>> the
> >>>>>>> code is generated perfectly!
> >>>>>>>
> >>>>>>> Other that this though, nothing else mentioned comes to mind.
> >>> Regarding
> >>>>>>> your other questions, no, all applicable functions are in the same
> >>>>> source
> >>>>>>> file, and no recursion is involved.
> >>>>>>>
> >>>>>>> Thanks for your help.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Olaf Spinczyk
> >>>>>>>> [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
> >>>>>>>> Sent: Wednesday, October 19, 2005 2:25 AM
> >>>>>>>> To: John C. Weicher
> >>>>>>>> Cc: aspectc-user at aspectc.org
> >>>>>>>> Subject: Re: [aspectc-user] Compiler Error - Related Error being
> >>> fixed
> >>>>>>> in
> >>>>>>>> (Version 1.0pre1: 10/2005)?
> >>>>>>>>
> >>>>>>>> Hi John,
> >>>>>>>>
> >>>>>>>> there is no general problem with around/call and before/execution
> >>>>> advice
> >>>>>>>> for the same function. I tried the following example without any
> >>>>>>>> problems (version 0.9.3):
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> void f1 () {
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> void f2 () {
> >>>>>>>> f1 ();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main () {
> >>>>>>>> f2 ();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> aspect Foo {
> >>>>>>>> advice call("% f1(...)") && within("% f2(...)") : around() {
> >>>>>>>> tjp->proceed ();
> >>>>>>>> printf ("after\n");
> >>>>>>>> }
> >>>>>>>> advice execution("% f1(...)") : before() {
> >>>>>>>> printf ("before\n");
> >>>>>>>> }
> >>>>>>>> };
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> What is the difference between your code and this test program?
> Are
> >>> any
> >>>>>>>> recursive functions involved? Is f2() declared in a separate
> header
> >>>>> file
> >>>>>>>> that does not belong to your project?
> >>>>>>>>
> >>>>>>>> The (HUGE) problem with version 0.9.3 is a different one. It is
> >>> related
> >>>>>>>> to introductions.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Olaf
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> John C. Weicher wrote:
> >>>>>>>>> I am running into an odd error during compilation that only
> >>>>>>>>> crops up
> >>>>>>>>> when I provide two separate advice calls which affect the same
> >>>>>>> function.
> >>>>>>>>> Simplified scenario exists where there is
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> someFunctionA(){
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> //blah blah
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> someFunctionB();
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> //blah blah
> >>>>>>>>>
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I have already defined an aspect with advice as follows:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> advice call("% %someFunctionB(...)") && within("%
> >>>>>>> %someFunctionA(...)")
> >>>>>>>>> : around() { //blah blah }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Obviously I am trying to call around function B when called from
> >>>>>>> within
> >>>>>>>>> A (I do some other stuff, and then let it proceed). This
> weaves,
> >>>>>>>>> parses, compiles and runs beautifully. I've been using this in
> a
> >>>>>>>>> working application for some time now.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> A new situation has arisen for me now where in addition to the
> >>>>>>>>> above
> >>>>>>>>> (situation is the same, and the previous advice block is also
> >>>>>>>>> still
> >>>>>>>>> needed and in place), I ALSO want to define an additional advice
> >>> block
> >>>>>>>>> to perform some operations before the execution of function A,
> >>>>>>>>> done
> >>> as
> >>>>>>>>> follows:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> advice execution("% %someFunctionA(...)") : before() { // blah
> >>>>>>>>> blah
> >>> }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This is causing problems. Weaving still occurs without error,
> but
> >>>>>>> when
> >>>>>>>>> I then try to compile weaved code, I receive the following error
> >>>>>>>>> (changed the function names to match my fake example above, so
> it
> >>>>>>> makes
> >>>>>>>>> sense):
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> : In function `int someFunctionA(args args args.)':
> >>>>>>>>>
> >>>>>>>>> :4: `__exec_old_someFunctionA' undeclared (first use this
> >>>>>>>>> function)
> >>>>>>>>>
> >>>>>>>>> :4: (Each undeclared identifier is reported only once for each
> >>>>>>> function
> >>>>>>>> it
> >>>>>>>>> appears in.)
> >>>>>>>>>
> >>>>>>>>> ./thefile.c: In function `int __exec_old_someFunctionA(args arg
> >>>>>>> args)':
> >>>>>>>>> ./thefile.c:280: `int __exec_old_someFunctionA(args args args)
> >>>>>>>>>
> >>>>>>>>> ' used prior to declaration
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> And sure enough, when I go into the file the inline definition
> for
> >>>>>>>>> __exec_old_someFunctionA is coming after the modified call to
> it.
> >>> But
> >>>>>>> I
> >>>>>>>>> didn't think this mattered with inline functions.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I apologize for the lengthy post, but I am definitely
> >>>>>>>>> confused. If
> >>> I
> >>>>>>>>> take the new additional advice block back out, everything
> compiles
> >>>>>>> fine
> >>>>>>>>> again.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I also noticed that although that it specifically mentions only
> >>>>>>> classes,
> >>>>>>>>> this sounds very similar to the issue that is supposed to be
> fixed
> >>> in
> >>>>>>>>> the new release mentioned on the Roadmap page: "fix for the HUGE
> >>>>>>> problem
> >>>>>>>>> of ac++ 0.9.3 that causes parse errors, when an aspect defines
> >>>>>>>>> code
> >>>>>>>>> advice for a class into which it also introduces new
> >>>>>>> functions/members".
> >>>>>>>>> Is this the case, and if so is there a workaround in the
> meantime?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----------------------------------------------------------------
> ----
> >>>>>>>>>
> >>> --
> >>>>>>> --
> >>>>>>>>> _______________________________________________
> >>>>>>>>> aspectc-user mailing list
> >>>>>>>>> aspectc-user at aspectc.org
> >>>>>>>>> http://www.aspectc.org/mailman/listinfo/aspectc-user
> >>>>>> _______________________________________________
> >>>>>> aspectc-user mailing list
> >>>>>> aspectc-user at aspectc.org
> >>>>>> http://www.aspectc.org/mailman/listinfo/aspectc-user
> >>>> _______________________________________________
> >>>> aspectc-user mailing list
> >>>> aspectc-user at aspectc.org
> >>>> http://www.aspectc.org/mailman/listinfo/aspectc-user
> >>
> >> _______________________________________________
> >> aspectc-user mailing list
> >> aspectc-user at aspectc.org
> >> http://www.aspectc.org/mailman/listinfo/aspectc-user
> >
> > _______________________________________________
> > aspectc-user mailing list
> > aspectc-user at aspectc.org
> > http://www.aspectc.org/mailman/listinfo/aspectc-user
More information about the aspectc-user
mailing list