Menu
▾
▴
takocompiler-developers — Issues affecting developers of the Tako compiler.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
(20) |
Oct
(2) |
Nov
|
Dec
|
|---|
|
From: Al F. <al...@at...> - 2005-10-02 23:34:27
|
Hello Professor, I have a question about how you would like to handle ensures and requires clauses in interfaces. In our discussion this past week, you had indicated a desire to have ensures and requires clauses for interfaces, and these would be associated with the method signature of the interface. This does impose some restrictions on these clauses: 1. One issue is that no variables defined within the scope of the method can be used in the clause, because at the time of method definition in the interface there is no implementation. This makes sense, because ensures and requires clauses deal with exit and entry conditions. 2. Another issue is that field definitions in interfaces seem to be more difficult to use. For example, they seem to be implicitly defined as final, and when I attempt to create one that is not initialized I get a syntax error. While it is possible to define variables, it is a bit more clumsy. However, without these fields, the clauses are not as valuable. 3. I assume that an important thing would be to be able to test preconditions and postconditions on parameters passed to a method as well as the return value. However, if this is the case, the implementation will need to be significantly more complex due to the need to provide local variables (a limited version of #1). Your thoughts appreciated. Thanks! -Al |
|
From: Al F. <al...@at...> - 2005-10-02 18:50:26
|
This may be of interest to the group as we poke around in class file bytecode -- I haven't tried it myself but it looks promising: http://resources.ej-technologies.com/jclasslib/doc/help.html |
|
From: Al F. <al...@at...> - 2005-09-28 11:52:01
|
Vidya, That's good news! -Al Vidya Chougule wrote: > Hi Al > > After trying different things and still unable to fix, I finally > called Jay over the weekend. He helped me fix the problem. > I was using jdk 1.4.2 and eclipse 3.0. I updated both of them > and download again a fresh copy of the project. Things worked then. > > -Vidya > > ----- Original Message ----- > *From:* Al Funk <mailto:al...@at...> > *Cc:* tak...@li... > <mailto:tak...@li...> > *Sent:* Tuesday, September 27, 2005 10:41 PM > *Subject:* Re: [Takocompiler-developers] Re:Getting errors in project > > Vidya, > > On #1 and #2, did you ensure you have received all added files? > Same with TakoASTViewerHelper. > > Your other errors look like a grammar problem I have seen. You > should get the latest Tkc.g file and re-run build.xml and see if > that helps. > > -Al > > > Vidya Chougule wrote: > >>Hi Jay & Al >> >>I synchronized my project with the reporsitory and I am getting these errors >>1) an error in the JClassDeclaration for the method >>genInnerJavaCode(TkcASTBase p). >>Error shown is TkcASTBase cannot be resolved (or is not a valid type) for >>the parameter p of the method. >>2) Related to same I am getting an error in TKCASTViewer class also at line >>number 975. >>3) In takoc.tkc.Main.java I am getting error at line 408. >> >>Another thing is I am trying to run the StackDoc.tako class , which I have >>checked in under build\test\data using the tako compiler. >>But I am getting the error below after I synched my code with CVS now. >> >>java.lang.Error: Unresolved compilation problems: >> >>TakoASTViewerHelper cannot be resolved >> >>swapvisitor.environment cannot be resolved or is not a field >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>AutoInitVisitor cannot be resolved or is not a type >> >>AutoInitVisitor cannot be resolved or is not a type >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>fnvisitor.environment cannot be resolved or is not a field >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>The operator == is undefined for the argument type(s) boolean, int >> >>at takoc.tkc.Main.run(Main.java:139) >> >>at takoc.tkc.Main.compile(Main.java:86) >> >>at takoc.tkc.Main.main(Main.java:77) >> >>Exception in thread "main" >> >>Am I missing something here or am I missing some files etc. Could you please >>let me know. >> >>Thanks >>-Vidya >> >>----- Original Message ----- >>From: "Al Funk" <al...@at...> >>To: <tak...@li...> >>Sent: Monday, September 19, 2005 10:31 PM >>Subject: [Takocompiler-developers] Current status >> >> >> >> >>>Hi Jay, >>> >>>A couple things I'm noticing with the changes -- >>> >>>1. The --destination argument does not work. Class files are placed >>>into the directory with the source. >>> >>>2. The system is having trouble finding TKObject again. I added it to >>>my classpath and it seems to solve the problem. >>> >>>-Al >>> >>> >>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: >>>Tame your development challenges with Apache's Geronimo App Server. >>>Download it for free - -and be entered to win a 42" plasma tv or your very >>>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>>_______________________________________________ >>>Takocompiler-developers mailing list >>>Tak...@li... >>>https://lists.sourceforge.net/lists/listinfo/takocompiler-developers >>> >>> >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: >>Tame your development challenges with Apache's Geronimo App Server. >>Download it for free - -and be entered to win a 42" plasma tv or your very >>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>_______________________________________________ >>Takocompiler-developers mailing list >>Tak...@li... >>https://lists.sourceforge.net/lists/listinfo/takocompiler-developers >> >> |
|
From: Vidya C. <vi...@vt...> - 2005-09-28 03:16:16
|
Hi Al After trying different things and still unable to fix, I finally called = Jay over the weekend. He helped me fix the problem. I was using jdk 1.4.2 and eclipse 3.0. I updated both of them and = download again a fresh copy of the project. Things worked then. -Vidya ----- Original Message -----=20 From: Al Funk=20 Cc: tak...@li...=20 Sent: Tuesday, September 27, 2005 10:41 PM Subject: Re: [Takocompiler-developers] Re:Getting errors in project Vidya, On #1 and #2, did you ensure you have received all added files? Same = with TakoASTViewerHelper. Your other errors look like a grammar problem I have seen. You should = get the latest Tkc.g file and re-run build.xml and see if that helps. -Al Vidya Chougule wrote:=20 Hi Jay & Al I synchronized my project with the reporsitory and I am getting these = errors 1) an error in the JClassDeclaration for the method genInnerJavaCode(TkcASTBase p). Error shown is TkcASTBase cannot be resolved (or is not a valid type) = for the parameter p of the method. 2) Related to same I am getting an error in TKCASTViewer class also at = line number 975. 3) In takoc.tkc.Main.java I am getting error at line 408. Another thing is I am trying to run the StackDoc.tako class , which I = have checked in under build\test\data using the tako compiler. But I am getting the error below after I synched my code with CVS now. java.lang.Error: Unresolved compilation problems: TakoASTViewerHelper cannot be resolved swapvisitor.environment cannot be resolved or is not a field The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int AutoInitVisitor cannot be resolved or is not a type AutoInitVisitor cannot be resolved or is not a type The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int fnvisitor.environment cannot be resolved or is not a field The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int The operator =3D=3D is undefined for the argument type(s) boolean, int at takoc.tkc.Main.run(Main.java:139) at takoc.tkc.Main.compile(Main.java:86) at takoc.tkc.Main.main(Main.java:77) Exception in thread "main" Am I missing something here or am I missing some files etc. Could you = please let me know. Thanks -Vidya ----- Original Message -----=20 From: "Al Funk" <al...@at...> To: <tak...@li...> Sent: Monday, September 19, 2005 10:31 PM Subject: [Takocompiler-developers] Current status Hi Jay, A couple things I'm noticing with the changes -- 1. The --destination argument does not work. Class files are placed into the directory with the source. 2. The system is having trouble finding TKObject again. I added it to my classpath and it seems to solve the problem. -Al ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your = very own Sony(tm)PSP. Click here to play: = http://sourceforge.net/geronimo.php _______________________________________________ Takocompiler-developers mailing list Tak...@li... https://lists.sourceforge.net/lists/listinfo/takocompiler-developers =20 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server.=20 Download it for free - -and be entered to win a 42" plasma tv or your = very own Sony(tm)PSP. Click here to play: = http://sourceforge.net/geronimo.php _______________________________________________ Takocompiler-developers mailing list Tak...@li... https://lists.sourceforge.net/lists/listinfo/takocompiler-developers |
|
From: Al F. <al...@at...> - 2005-09-28 02:41:12
|
Vidya, On #1 and #2, did you ensure you have received all added files? Same with TakoASTViewerHelper. Your other errors look like a grammar problem I have seen. You should get the latest Tkc.g file and re-run build.xml and see if that helps. -Al Vidya Chougule wrote: >Hi Jay & Al > >I synchronized my project with the reporsitory and I am getting these errors >1) an error in the JClassDeclaration for the method >genInnerJavaCode(TkcASTBase p). >Error shown is TkcASTBase cannot be resolved (or is not a valid type) for >the parameter p of the method. >2) Related to same I am getting an error in TKCASTViewer class also at line >number 975. >3) In takoc.tkc.Main.java I am getting error at line 408. > >Another thing is I am trying to run the StackDoc.tako class , which I have >checked in under build\test\data using the tako compiler. >But I am getting the error below after I synched my code with CVS now. > >java.lang.Error: Unresolved compilation problems: > >TakoASTViewerHelper cannot be resolved > >swapvisitor.environment cannot be resolved or is not a field > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >AutoInitVisitor cannot be resolved or is not a type > >AutoInitVisitor cannot be resolved or is not a type > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >fnvisitor.environment cannot be resolved or is not a field > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >The operator == is undefined for the argument type(s) boolean, int > >at takoc.tkc.Main.run(Main.java:139) > >at takoc.tkc.Main.compile(Main.java:86) > >at takoc.tkc.Main.main(Main.java:77) > >Exception in thread "main" > >Am I missing something here or am I missing some files etc. Could you please >let me know. > >Thanks >-Vidya > >----- Original Message ----- >From: "Al Funk" <al...@at...> >To: <tak...@li...> >Sent: Monday, September 19, 2005 10:31 PM >Subject: [Takocompiler-developers] Current status > > > > >>Hi Jay, >> >>A couple things I'm noticing with the changes -- >> >>1. The --destination argument does not work. Class files are placed >>into the directory with the source. >> >>2. The system is having trouble finding TKObject again. I added it to >>my classpath and it seems to solve the problem. >> >>-Al >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: >>Tame your development challenges with Apache's Geronimo App Server. >>Download it for free - -and be entered to win a 42" plasma tv or your very >>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>_______________________________________________ >>Takocompiler-developers mailing list >>Tak...@li... >>https://lists.sourceforge.net/lists/listinfo/takocompiler-developers >> >> > > > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. >Download it for free - -and be entered to win a 42" plasma tv or your very >own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Takocompiler-developers mailing list >Tak...@li... >https://lists.sourceforge.net/lists/listinfo/takocompiler-developers > > |
|
From: Vidya C. <vi...@vt...> - 2005-09-22 02:49:18
|
Hi Jay & Al I synchronized my project with the reporsitory and I am getting these errors 1) an error in the JClassDeclaration for the method genInnerJavaCode(TkcASTBase p). Error shown is TkcASTBase cannot be resolved (or is not a valid type) for the parameter p of the method. 2) Related to same I am getting an error in TKCASTViewer class also at line number 975. 3) In takoc.tkc.Main.java I am getting error at line 408. Another thing is I am trying to run the StackDoc.tako class , which I have checked in under build\test\data using the tako compiler. But I am getting the error below after I synched my code with CVS now. java.lang.Error: Unresolved compilation problems: TakoASTViewerHelper cannot be resolved swapvisitor.environment cannot be resolved or is not a field The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int AutoInitVisitor cannot be resolved or is not a type AutoInitVisitor cannot be resolved or is not a type The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int fnvisitor.environment cannot be resolved or is not a field The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int The operator == is undefined for the argument type(s) boolean, int at takoc.tkc.Main.run(Main.java:139) at takoc.tkc.Main.compile(Main.java:86) at takoc.tkc.Main.main(Main.java:77) Exception in thread "main" Am I missing something here or am I missing some files etc. Could you please let me know. Thanks -Vidya ----- Original Message ----- From: "Al Funk" <al...@at...> To: <tak...@li...> Sent: Monday, September 19, 2005 10:31 PM Subject: [Takocompiler-developers] Current status > Hi Jay, > > A couple things I'm noticing with the changes -- > > 1. The --destination argument does not work. Class files are placed > into the directory with the source. > > 2. The system is having trouble finding TKObject again. I added it to > my classpath and it seems to solve the problem. > > -Al > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Takocompiler-developers mailing list > Tak...@li... > https://lists.sourceforge.net/lists/listinfo/takocompiler-developers |
|
From: Al F. <al...@at...> - 2005-09-20 02:31:32
|
Hi Jay, A couple things I'm noticing with the changes -- 1. The --destination argument does not work. Class files are placed into the directory with the source. 2. The system is having trouble finding TKObject again. I added it to my classpath and it seems to solve the problem. -Al |
|
From: Al F. <al...@at...> - 2005-09-19 01:31:39
|
Professor,
Right, option #3 is an alternative of option #2.
As I see it, the difference between 2a and 2b is at what step we do the
final conversion to the if-then assert structure. It introduces an
intermediate AST structure on which the existing visitors can act without
knowledge of the specifics of an assert. The assert statement becomes a
block (initially with one statement), then the visitors act on it, then it
gets converted to an if-then when all the other transformations are done.
It centralizes the logic of how to handle assertions, and it enables us to
perform multiple visitor tasks on the "assert block" without worrying about
the details of how we will make an assert work. I haven't quite thought
through exactly how the final step will work but my gut tells me it is
workable. The only gotcha I can think of is if we require side-effecting
behavior of the code Jay is inserting in the visitors. I can't imagine that
this would be the case.
So if we decide to do 2b, then I can add in the feature. If we decide to go
toward 2a, then it will probably mainly be up to Jay to integrate it,
because it will need to go into his visitor code. Unless you want us to
collaborate on those visitors.
-Al
-----Original Message-----
From: tak...@li...
[mailto:tak...@li...]On Behalf Of
Gregory Kulczycki
Sent: Monday, September 12, 2005 11:31 AM
To: tak...@li...
Subject: Re: [Takocompiler-developers] Thoughts on handling decomposition
of assert expression
Al, It sounds like your option #3 is an alternative implementation to get
you to option #2. So, as I understand it, you have two options:
1. make assert statement into a method.
2. make assert statement into a if-then statement
2a. Use some "obvious" implementation
2b. Use implementation from your #3.
If this is the case, I would have to think about what the differences are
between implementations 2a and 2b.
Greg
On Sep 11, 2005, at 11:15 PM, Jyotindra Vasudeo wrote:
Hi Al,
This is one method Dr Greg and I talked about, which may do for now.
This is similar to your option 2.
public boolean assertionEnabled = false;
static {
assert assertionEnabled = true;
}
and when we have the assert statement eg
assert f(x);
will become :
if(assertionEnabled) {
assert f(x);
}
and when it is decomposed it becomes
if(assertionEnabled) {
boolean_func[0] = f(x);
$this = param[0];
x = param[1];
assert boolean_func[0];
}
So if the assertions is disabled the above code will not be executed. If
you see any drawbacks of this method please comment. Bye
-Jay
P.S: I have still not updated your file. I will do that tommorow
morning.
On 9/11/05, Al Funk <al...@at...> wrote:
All,
The problem: because we are decomposing function calls, we have a
problem handling assert statements. In particular, the concern is to avoid
side-effecting statements called during an assert behaving differently in
Tako than in Java due to decomposition.
After some thought, here are the options I see regarding handling of
assertion expression decomposition. #3 is something of a radical concept but
it may offer a solution to this problem and others we will face going
forward.
1. Use a function
Pros: Logical, immediate encapsulation of functionality. Also nice
because it can be done without consideration for the decomposition visitor's
functionality.
Cons: Requires passing in of local-scope variables. Requires handling
of potential exceptions.
2. Create an if-block when performing decomposition activities.
This would mean that one of our first steps would be "wrappering" the
assert statement in the if block.
An example would be:
assert f(x);
becomes:
if (assertionsEnabled()) {
assert f(x);
}
Then decomposition would adjust the location of the assert with each
transformation step.
3. Re-engineer assert object in AST.
This one is intriguing as it resolves a number of issues and creates a
new paradigm for managing AST transformations.
This would take advantage of the fact that the intermediate AST
structure does not need to precisely parallel the tako input code grammar
nor does it need to precisely reflect the output Java code.
Essentially, right after analysis we would create an intermediate AST
assert object that accepted a block. The JAssertStatement that I'm currently
working with would be changed to XAssertBlock, in the following way:
assert f(x);
internally becomes:
assert { f(x); }
Admittedly meaningless as Java code.
Then the decomposition visitor could come in and see and modify the
block.
At the end, we would then resolve the XAssertBlock as in #2; so it
would be manipulated to become a tree of JIfStatement with a block and a
JAssertStatement at the end.
Pros: Easy for visitors to manipulate, as they expect blocks.
Cons: Looks strange when viewing intermediate structure. Would need
"X" object to be resolved by a late-term visitor. May be tricky if we do
mid-term analysis.
All, please let me know what you think.
-Al
|
|
From: Al F. <al...@at...> - 2005-09-14 01:47:32
|
So where would you like to add this code? To one of the new visitors?
-Al
-----Original Message-----
From: tak...@li...
[mailto:tak...@li...]On Behalf Of
Jyotindra Vasudeo
Sent: Sunday, September 11, 2005 11:15 PM
To: tak...@li...
Subject: Re: [Takocompiler-developers] Thoughts on handling decomposition
of assert expression
Hi Al,
This is one method Dr Greg and I talked about, which may do for now. This
is similar to your option 2.
public boolean assertionEnabled = false;
static {
assert assertionEnabled = true;
}
and when we have the assert statement eg
assert f(x);
will become :
if(assertionEnabled) {
assert f(x);
}
and when it is decomposed it becomes
if(assertionEnabled) {
boolean_func[0] = f(x);
$this = param[0];
x = param[1];
assert boolean_func[0];
}
So if the assertions is disabled the above code will not be executed. If
you see any drawbacks of this method please comment. Bye
-Jay
P.S: I have still not updated your file. I will do that tommorow morning.
On 9/11/05, Al Funk <al...@at...> wrote:
All,
The problem: because we are decomposing function calls, we have a
problem handling assert statements. In particular, the concern is to avoid
side-effecting statements called during an assert behaving differently in
Tako than in Java due to decomposition.
After some thought, here are the options I see regarding handling of
assertion expression decomposition. #3 is something of a radical concept
but it may offer a solution to this problem and others we will face going
forward.
1. Use a function
Pros: Logical, immediate encapsulation of functionality. Also nice
because it can be done without consideration for the decomposition visitor's
functionality.
Cons: Requires passing in of local-scope variables. Requires handling
of potential exceptions.
2. Create an if-block when performing decomposition activities.
This would mean that one of our first steps would be "wrappering" the
assert statement in the if block.
An example would be:
assert f(x);
becomes:
if (assertionsEnabled()) {
assert f(x);
}
Then decomposition would adjust the location of the assert with each
transformation step.
3. Re-engineer assert object in AST.
This one is intriguing as it resolves a number of issues and creates a
new paradigm for managing AST transformations.
This would take advantage of the fact that the intermediate AST
structure does not need to precisely parallel the tako input code grammar
nor does it need to precisely reflect the output Java code.
Essentially, right after analysis we would create an intermediate AST
assert object that accepted a block. The JAssertStatement that I'm
currently working with would be changed to XAssertBlock, in the following
way:
assert f(x);
internally becomes:
assert { f(x); }
Admittedly meaningless as Java code.
Then the decomposition visitor could come in and see and modify the
block.
At the end, we would then resolve the XAssertBlock as in #2; so it would
be manipulated to become a tree of JIfStatement with a block and a
JAssertStatement at the end.
Pros: Easy for visitors to manipulate, as they expect blocks.
Cons: Looks strange when viewing intermediate structure. Would need "X"
object to be resolved by a late-term visitor. May be tricky if we do
mid-term analysis.
All, please let me know what you think.
-Al
|
|
From: Al F. <al...@at...> - 2005-09-14 01:41:58
|
So should I archive and purge the old Kopi code? -Al -----Original Message----- From: tak...@li... [mailto:tak...@li...]On Behalf Of Gregory Kulczycki Sent: Monday, September 12, 2005 12:09 PM To: tak...@li... Subject: Re: [Takocompiler-developers] Removal of old assertion code Al, We will be getting rid of all "@" signs from keywords. I assume this is an easy change that can be made at the parser level and does not affect the AST code. For release #1, I definitely want assert statements, but I don't really care about requires and ensures clauses - those will come in the second release. Greg On Sep 12, 2005, at 11:34 AM, Al Funk wrote: > All, > > Right now I'm working on deactivating the old assertion code > associated with Kopi assertions. I've successfully eliminated the > fields and methods (e.g., class$) associated with the old assertion > processing. I've created a JAssertStatement object that parallels > the Java "assert" statement. > > These changes mean that the standard Java 1.4 assert statement will > be passed through unmolested (at least by the Kopi code). However, > a side effect is that the @ensure and @require clauses will no > longer work until we recode these. > > Here are some outstanding questions: > > - Permit @assert? Right now, it is permitted syntax but will > result in errors because the supporting code is no longer being > generated. > - Activate @require and @ensure? Same status as @assert as > described above > - Activate class invariants? (Extended assertion feature, I assume no) > > -Al > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > Takocompiler-developers mailing list > Tak...@li... > https://lists.sourceforge.net/lists/listinfo/takocompiler-developers > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Takocompiler-developers mailing list Tak...@li... https://lists.sourceforge.net/lists/listinfo/takocompiler-developers |
|
From: Gregory K. <gr...@vt...> - 2005-09-12 16:08:53
|
Al, We will be getting rid of all "@" signs from keywords. I assume this is an easy change that can be made at the parser level and does not affect the AST code. For release #1, I definitely want assert statements, but I don't really care about requires and ensures clauses - those will come in the second release. Greg On Sep 12, 2005, at 11:34 AM, Al Funk wrote: > All, > > Right now I'm working on deactivating the old assertion code > associated with Kopi assertions. I've successfully eliminated the > fields and methods (e.g., class$) associated with the old assertion > processing. I've created a JAssertStatement object that parallels > the Java "assert" statement. > > These changes mean that the standard Java 1.4 assert statement will > be passed through unmolested (at least by the Kopi code). However, > a side effect is that the @ensure and @require clauses will no > longer work until we recode these. > > Here are some outstanding questions: > > - Permit @assert? Right now, it is permitted syntax but will > result in errors because the supporting code is no longer being > generated. > - Activate @require and @ensure? Same status as @assert as > described above > - Activate class invariants? (Extended assertion feature, I assume no) > > -Al > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > Takocompiler-developers mailing list > Tak...@li... > https://lists.sourceforge.net/lists/listinfo/takocompiler-developers > |
|
From: Al F. <al...@at...> - 2005-09-12 15:35:05
|
All, Right now I'm working on deactivating the old assertion code associated with Kopi assertions. I've successfully eliminated the fields and methods (e.g., class$) associated with the old assertion processing. I've created a JAssertStatement object that parallels the Java "assert" statement. These changes mean that the standard Java 1.4 assert statement will be passed through unmolested (at least by the Kopi code). However, a side effect is that the @ensure and @require clauses will no longer work until we recode these. Here are some outstanding questions: - Permit @assert? Right now, it is permitted syntax but will result in errors because the supporting code is no longer being generated. - Activate @require and @ensure? Same status as @assert as described above - Activate class invariants? (Extended assertion feature, I assume no) -Al |
|
From: Gregory K. <gr...@vt...> - 2005-09-12 15:31:15
|
Al, It sounds like your option #3 is an alternative implementation to
get you to option #2. So, as I understand it, you have two options:
1. make assert statement into a method.
2. make assert statement into a if-then statement
2a. Use some "obvious" implementation
2b. Use implementation from your #3.
If this is the case, I would have to think about what the differences
are between implementations 2a and 2b.
Greg
On Sep 11, 2005, at 11:15 PM, Jyotindra Vasudeo wrote:
> Hi Al,
>
> This is one method Dr Greg and I talked about, which may do for
> now. This is similar to your option 2.
>
> public boolean assertionEnabled = false;
> static {
> assert assertionEnabled = true;
> }
>
> and when we have the assert statement eg
>
> assert f(x);
>
> will become :
>
> if(assertionEnabled) {
> assert f(x);
> }
>
> and when it is decomposed it becomes
>
> if(assertionEnabled) {
> boolean_func[0] = f(x);
> $this = param[0];
> x = param[1];
> assert boolean_func[0];
> }
>
> So if the assertions is disabled the above code will not be
> executed. If you see any drawbacks of this method please comment. Bye
>
> -Jay
>
> P.S: I have still not updated your file. I will do that tommorow
> morning.
>
> On 9/11/05, Al Funk <al...@at...> wrote:
> All,
>
> The problem: because we are decomposing function calls, we have a
> problem handling assert statements. In particular, the concern is
> to avoid side-effecting statements called during an assert behaving
> differently in Tako than in Java due to decomposition.
>
> After some thought, here are the options I see regarding handling
> of assertion expression decomposition. #3 is something of a
> radical concept but it may offer a solution to this problem and
> others we will face going forward.
>
> 1. Use a function
>
> Pros: Logical, immediate encapsulation of functionality. Also nice
> because it can be done without consideration for the decomposition
> visitor's functionality.
> Cons: Requires passing in of local-scope variables. Requires
> handling of potential exceptions.
>
>
> 2. Create an if-block when performing decomposition activities.
>
> This would mean that one of our first steps would be "wrappering"
> the assert statement in the if block.
>
> An example would be:
>
> assert f(x);
>
> becomes:
>
> if (assertionsEnabled()) {
> assert f(x);
> }
>
> Then decomposition would adjust the location of the assert with
> each transformation step.
>
>
> 3. Re-engineer assert object in AST.
>
> This one is intriguing as it resolves a number of issues and
> creates a new paradigm for managing AST transformations.
>
> This would take advantage of the fact that the intermediate AST
> structure does not need to precisely parallel the tako input code
> grammar nor does it need to precisely reflect the output Java code.
>
> Essentially, right after analysis we would create an intermediate
> AST assert object that accepted a block. The JAssertStatement that
> I'm currently working with would be changed to XAssertBlock, in the
> following way:
>
> assert f(x);
>
> internally becomes:
>
> assert { f(x); }
>
> Admittedly meaningless as Java code.
>
> Then the decomposition visitor could come in and see and modify the
> block.
>
> At the end, we would then resolve the XAssertBlock as in #2; so it
> would be manipulated to become a tree of JIfStatement with a block
> and a JAssertStatement at the end.
>
> Pros: Easy for visitors to manipulate, as they expect blocks.
> Cons: Looks strange when viewing intermediate structure. Would
> need "X" object to be resolved by a late-term visitor. May be
> tricky if we do mid-term analysis.
>
>
> All, please let me know what you think.
>
> -Al
>
>
|
|
From: Al F. <al...@at...> - 2005-09-12 04:50:15
|
Jay,
That sounds reasonable. The only drawback I see is that it will need to be
done across a couple of your visitor steps and potentially during your
decomposition work. This could make it a bit complex. I can't see any
drawbacks in the end result.
-Al
-----Original Message-----
From: tak...@li...
[mailto:tak...@li...]On Behalf Of
Jyotindra Vasudeo
Sent: Sunday, September 11, 2005 11:15 PM
To: tak...@li...
Subject: Re: [Takocompiler-developers] Thoughts on handling decomposition
of assert expression
Hi Al,
This is one method Dr Greg and I talked about, which may do for now. This
is similar to your option 2.
public boolean assertionEnabled = false;
static {
assert assertionEnabled = true;
}
and when we have the assert statement eg
assert f(x);
will become :
if(assertionEnabled) {
assert f(x);
}
and when it is decomposed it becomes
if(assertionEnabled) {
boolean_func[0] = f(x);
$this = param[0];
x = param[1];
assert boolean_func[0];
}
So if the assertions is disabled the above code will not be executed. If
you see any drawbacks of this method please comment. Bye
-Jay
P.S: I have still not updated your file. I will do that tommorow morning.
On 9/11/05, Al Funk <al...@at...> wrote:
All,
The problem: because we are decomposing function calls, we have a
problem handling assert statements. In particular, the concern is to avoid
side-effecting statements called during an assert behaving differently in
Tako than in Java due to decomposition.
After some thought, here are the options I see regarding handling of
assertion expression decomposition. #3 is something of a radical concept
but it may offer a solution to this problem and others we will face going
forward.
1. Use a function
Pros: Logical, immediate encapsulation of functionality. Also nice
because it can be done without consideration for the decomposition visitor's
functionality.
Cons: Requires passing in of local-scope variables. Requires handling
of potential exceptions.
2. Create an if-block when performing decomposition activities.
This would mean that one of our first steps would be "wrappering" the
assert statement in the if block.
An example would be:
assert f(x);
becomes:
if (assertionsEnabled()) {
assert f(x);
}
Then decomposition would adjust the location of the assert with each
transformation step.
3. Re-engineer assert object in AST.
This one is intriguing as it resolves a number of issues and creates a
new paradigm for managing AST transformations.
This would take advantage of the fact that the intermediate AST
structure does not need to precisely parallel the tako input code grammar
nor does it need to precisely reflect the output Java code.
Essentially, right after analysis we would create an intermediate AST
assert object that accepted a block. The JAssertStatement that I'm
currently working with would be changed to XAssertBlock, in the following
way:
assert f(x);
internally becomes:
assert { f(x); }
Admittedly meaningless as Java code.
Then the decomposition visitor could come in and see and modify the
block.
At the end, we would then resolve the XAssertBlock as in #2; so it would
be manipulated to become a tree of JIfStatement with a block and a
JAssertStatement at the end.
Pros: Easy for visitors to manipulate, as they expect blocks.
Cons: Looks strange when viewing intermediate structure. Would need "X"
object to be resolved by a late-term visitor. May be tricky if we do
mid-term analysis.
All, please let me know what you think.
-Al
|
|
From: Jyotindra V. <jva...@gm...> - 2005-09-12 03:15:31
|
Hi Al,
This is one method Dr Greg and I talked about, which may do for now. This=
=20
is similar to your option 2.
public boolean assertionEnabled =3D false;
static {
assert assertionEnabled =3D true;
}
and when we have the assert statement eg
assert f(x);
will become :
if(assertionEnabled) {
assert f(x);
}
and when it is decomposed it becomes
if(assertionEnabled) {
boolean_func[0] =3D f(x);
$this =3D param[0];
x =3D param[1];
assert boolean_func[0];
}
So if the assertions is disabled the above code will not be executed. If yo=
u=20
see any drawbacks of this method please comment. Bye
-Jay
P.S: I have still not updated your file. I will do that tommorow morning.
On 9/11/05, Al Funk <al...@at...> wrote:=20
>=20
> All,
>=20
> *The problem*: because we are decomposing function calls, we have a=20
> problem handling assert statements. In particular, the concern is to avoi=
d=20
> side-effecting statements called during an assert behaving differently in=
=20
> Tako than in Java due to decomposition.
>=20
> After some thought, here are the options I see regarding handling of=20
> assertion expression decomposition. #3 is something of a radical concept =
but=20
> it may offer a solution to this problem and others we will face going=20
> forward.
>=20
> *1. Use a function*
>=20
> Pros: Logical, immediate encapsulation of functionality. Also nice becaus=
e=20
> it can be done without consideration for the decomposition visitor's=20
> functionality.
> Cons: Requires passing in of local-scope variables. Requires handling of=
=20
> potential exceptions.
>=20
>=20
> *2. Create an if-block when performing decomposition activities.*
>=20
> This would mean that one of our first steps would be "wrappering" the=20
> assert statement in the if block.
>=20
> An example would be:
>=20
> assert f(x);
>=20
> becomes:
>=20
> if (assertionsEnabled()) {
> assert f(x);
> }
>=20
> Then decomposition would adjust the location of the assert with each=20
> transformation step.
>=20
>=20
> *3. Re-engineer assert object in AST.*
>=20
> This one is intriguing as it resolves a number of issues and creates a ne=
w=20
> paradigm for managing AST transformations.
>=20
> This would take advantage of the fact that the intermediate AST structure=
=20
> does not need to precisely parallel the tako input code grammar nor does =
it=20
> need to precisely reflect the output Java code.
>=20
> Essentially, right after analysis we would create an intermediate AST=20
> assert object that accepted a block. The JAssertStatement that I'm curren=
tly=20
> working with would be changed to XAssertBlock, in the following way:
>=20
> assert f(x);
>=20
> internally becomes:
>=20
> assert { f(x); }
>=20
> Admittedly meaningless as Java code.
>=20
> Then the decomposition visitor could come in and see and modify the block=
.
>=20
> At the end, we would then resolve the XAssertBlock as in #2; so it would=
=20
> be manipulated to become a tree of JIfStatement with a block and a=20
> JAssertStatement at the end.
>=20
> Pros: Easy for visitors to manipulate, as they expect blocks.
> Cons: Looks strange when viewing intermediate structure. Would need "X"=
=20
> object to be resolved by a late-term visitor. May be tricky if we do=20
> mid-term analysis.
>=20
>=20
> All, please let me know what you think.
>=20
> -Al
>=20
>
|
|
From: Al F. <al...@at...> - 2005-09-12 00:00:22
|
All,
*The problem*: because we are decomposing function calls, we have a
problem handling assert statements. In particular, the concern is to
avoid side-effecting statements called during an assert behaving
differently in Tako than in Java due to decomposition.
After some thought, here are the options I see regarding handling of
assertion expression decomposition. #3 is something of a radical
concept but it may offer a solution to this problem and others we will
face going forward.
_1. Use a function_
Pros: Logical, immediate encapsulation of functionality. Also nice
because it can be done without consideration for the decomposition
visitor's functionality.
Cons: Requires passing in of local-scope variables. Requires handling
of potential exceptions.
_2. Create an if-block when performing decomposition activities._
This would mean that one of our first steps would be "wrappering" the
assert statement in the if block.
An example would be:
assert f(x);
becomes:
if (assertionsEnabled()) {
assert f(x);
}
Then decomposition would adjust the location of the assert with each
transformation step.
_3. Re-engineer assert object in AST._
This one is intriguing as it resolves a number of issues and creates a
new paradigm for managing AST transformations.
This would take advantage of the fact that the intermediate AST
structure does not need to precisely parallel the tako input code
grammar nor does it need to precisely reflect the output Java code.
Essentially, right after analysis we would create an intermediate AST
assert object that accepted a block. The JAssertStatement that I'm
currently working with would be changed to XAssertBlock, in the
following way:
assert f(x);
internally becomes:
assert { f(x); }
Admittedly meaningless as Java code.
Then the decomposition visitor could come in and see and modify the block.
At the end, we would then resolve the XAssertBlock as in #2; so it would
be manipulated to become a tree of JIfStatement with a block and a
JAssertStatement at the end.
Pros: Easy for visitors to manipulate, as they expect blocks.
Cons: Looks strange when viewing intermediate structure. Would need "X"
object to be resolved by a late-term visitor. May be tricky if we do
mid-term analysis.
All, please let me know what you think.
-Al
|
|
From: Jyotindra V. <jva...@gm...> - 2005-09-08 20:34:54
|
Hey Al, Sorry for the delay, but i have made all my changes, I would suggest you= =20 refresh your copy from the CVS to get the new updates. Bye -Jay |
|
From: Al F. <al...@at...> - 2005-09-06 02:21:43
|
Professor, I realized that the plan of "methodizing" assertions has one minor and one more substantial flaw. The first flaw, which we can work around, is that any exceptions thrown when evaluating the expression (say it is already a method expression) must be thrown from the new method. While this adds complexity, it is not unworkable. The second flaw is that upon "methodization", any variables which were in local scope of the expression are no longer. While there are workarounds -- setting globals to store the values, or passing them in as method parameters -- none of them are very clean. I'm going to think on the alternatives. -Al -----Original Message----- From: tak...@li... [mailto:tak...@li...]On Behalf Of Gregory Kulczycki Sent: Sunday, September 04, 2005 12:54 AM To: tak...@li... Subject: Re: [Takocompiler-developers] Assertions support For the first release (late September, early October?) I simply want to see Java-1.4-style assertions implemented. Even so, that means that we have to worry about how to allow side-effecting functions inside of assert statements. So I guess the answer would be "simple" for release 1. Eventually, we want to surpass Kopi's use of assertions by including not only ensures and requires clauses, but also model variables and "represents" clauses, similar to JML. Greg On Sep 3, 2005, at 8:55 PM, Al Funk wrote: > Professor, > > If we're going to move to Java 1.5 for the actual code compilation, > then how much of the Kopi "@" style assertion code do we want to > bring forward (and complete implementation of)? All, some, or > none? Full or simple? > > Thanks! > > -Al > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > Takocompiler-developers mailing list > Tak...@li... > https://lists.sourceforge.net/lists/listinfo/takocompiler-developers > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Takocompiler-developers mailing list Tak...@li... https://lists.sourceforge.net/lists/listinfo/takocompiler-developers |
|
From: Gregory K. <gr...@vt...> - 2005-09-04 04:53:54
|
For the first release (late September, early October?) I simply want to see Java-1.4-style assertions implemented. Even so, that means that we have to worry about how to allow side-effecting functions inside of assert statements. So I guess the answer would be "simple" for release 1. Eventually, we want to surpass Kopi's use of assertions by including not only ensures and requires clauses, but also model variables and "represents" clauses, similar to JML. Greg On Sep 3, 2005, at 8:55 PM, Al Funk wrote: > Professor, > > If we're going to move to Java 1.5 for the actual code compilation, > then how much of the Kopi "@" style assertion code do we want to > bring forward (and complete implementation of)? All, some, or > none? Full or simple? > > Thanks! > > -Al > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > Takocompiler-developers mailing list > Tak...@li... > https://lists.sourceforge.net/lists/listinfo/takocompiler-developers > |
|
From: Al F. <al...@at...> - 2005-09-04 00:55:41
|
Professor, If we're going to move to Java 1.5 for the actual code compilation, then how much of the Kopi "@" style assertion code do we want to bring forward (and complete implementation of)? All, some, or none? Full or simple? Thanks! -Al |
|
From: Jyotindra V. <jva...@gm...> - 2005-09-03 21:13:18
|
Hey Al,
We may need to meet in the next week to plan out a strategy to perfect the=
=20
pretty printer and think on the assertions stuff. When are you free next=20
week?
-Jay
On 9/3/05, Al Funk <al...@at...> wrote:=20
>=20
> All,
>=20
> Here are answers to some open questions:
>=20
> 1. Prof K and I discussed whether Java assertions can have blocks
> rather than single expressions; the answer is no (as expected)
> 2. Is there an easy way to detect availability of assertions if we have
> assertions available in bytecode generator (as we do with the new model
> of using Java 5):?
>=20
> Yes, here is sample code from the docs by the Kopi author:
>=20
> static {
> boolean assertsEnabled =3D false;
> assert assertsEnabled =3D true;
> if (!assertsEnabled)
> throw new RuntimeException("Asserts must be enabled.");
> }
>=20
> Of course, in most cases we would not need to throw the exception.
>=20
> -Al
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Takocompiler-developers mailing list
> Tak...@li...
> https://lists.sourceforge.net/lists/listinfo/takocompiler-developers
>
|
|
From: Al F. <al...@at...> - 2005-09-03 19:19:18
|
All,
Here are answers to some open questions:
1. Prof K and I discussed whether Java assertions can have blocks
rather than single expressions; the answer is no (as expected)
2. Is there an easy way to detect availability of assertions if we have
assertions available in bytecode generator (as we do with the new model
of using Java 5):?
Yes, here is sample code from the docs by the Kopi author:
static {
boolean assertsEnabled = false;
assert assertsEnabled = true;
if (!assertsEnabled)
throw new RuntimeException("Asserts must be enabled.");
}
Of course, in most cases we would not need to throw the exception.
-Al
|
|
From: Al F. <al...@ma...> - 2005-08-31 20:32:07
|
Jay, If you use the -g option, the AST viewer will print out Java code with a .gen extension. The field is numeric, so you can use -g 9 (I think 9 is the final one, you can check the source in Main to see what the last checkpoint is). Tomorrow I will experiment with Java 1.5 and see if I can reproduce your results. That's very odd, I wouldn't have expected assertions to impact the compiler since I didn't know they used assertions. Maybe if we run -g with assertions enabled we can find out where the assertion is being triggered. -Al Jyotindra Vasudeo wrote: > Hey Al, > > Yesterday we ported the compiler to java 1.5 and the ASTViewer isn't > working properly. It has started giving a Exception: null at all debug > points (even after the checkBody), can you please check it out. Also i > want to create a TkcJavaPrettyPrinter visitor based on your ASTViewer, > for pretty printing the code to a file, what would be the best way to > do that. Thanks. > > -Jay |
|
From: Jyotindra V. <jva...@gm...> - 2005-08-30 21:55:15
|
Hi Al, I was using the -s 1.3 option to turn off assertions, it seems if i turn= =20 off assertions, it doesn't work with that option. When i turned that option= =20 it started working.=20 -Jay |
|
From: Jyotindra V. <jva...@gm...> - 2005-08-30 17:47:21
|
Hey Al, Yesterday we ported the compiler to java 1.5 and the ASTViewer isn't=20 working properly. It has started giving a Exception: null at all debug=20 points (even after the checkBody), can you please check it out. Also i want= =20 to create a TkcJavaPrettyPrinter visitor based on your ASTViewer, for prett= y=20 printing the code to a file, what would be the best way to do that. Thanks. -Jay |
