srcml-discussion — General discussions about the SrcML framework

Re: [SrcML] build directories in CVS

[Dennis W. <den...@in...>]

Frank Raiser wrote:
>Apparently the build/ directories got accidentally imported into the
>CVS tree for the plugins in the srcml module. I have manually removed
>the .class files from the CVS, but the directories still remain. I hope
>there were no problems caused by this (considering it seems to have been
>in CVS for over 2 weeks now I doubt anyone else came across it yet).
>  
Actually - I came across it and wanted to suggest to add "class" to our 
cvsignore.

-
Dennis

[SrcML] build directories in CVS

[Frank R. <fra...@in...>]

Apparently the build/ directories got accidentally imported into the
CVS tree for the plugins in the srcml module. I have manually removed
the .class files from the CVS, but the directories still remain. I hope
there were no problems caused by this (considering it seems to have been
in CVS for over 2 weeks now I doubt anyone else came across it yet).
I've posted a SourceForge support request to get those build/ directories
removed as well:
https://sourceforge.net/tracker/index.php?func=detail&aid=1212012&group_id=1&atid=200001

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

The illusion of progress can be achieved by simply rearranging the terms
of description so that new acronyms are created. (Scott Smith)

Re: [SrcML] static analyzis

[Frank R. <fra...@in...>]

On Sun, May 29, 2005 at 11:47:12PM +0200, Leif Bladt wrote:
> >So if I understand that correctly the AnalyzerPlatform still only
> >has a execute() method without parameters, but implicitly calls
> >the plugin with execute(getDocuments()) ?
> exactly. Do you see any problems with this?

not at all. just wanted to make sure.

> >Sounds good. Although you could do the same for the View too. The
> >Vector of SrcML documents has to be created 'somewhere'. In your
> >case the AnalyzerPlatform takes care of it and in the case of the
> >ViewPlatform the callee would have to use the same Vector for every
> >chosen ViewPlugin. But from a design point of view your solution
> >looks better to me as it's emphasizing the platform concept more
> >clearly.
> ok, but this could take 'til wednesday.

I was not suggesting you change anything. We should rather discuss if
it's worth to restructure the ViewPlatform the way the AnalyzerPlatform
works to get a more unified interface for handling the SrcML documents
in those platforms.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Software is like sex: It's better when it's free. (Linus Torvalds)

Re: [SrcML] static analyzis

[Leif B. <lei...@in...>]

> You can change that into
> public abstract Vector<AnalyzerResult> execute(
>     Vector<SrcML> f_docs) throws PluginException
> now that we 'support' java 1.5 to increase the type safety.
> (same for the methods below)
ok

>>     public Vector addDocument(SrcML f_srcml) {}
>>     public Vector getDocuments() {}
>>     public void removeAllDocuments() {}
>>     public Vector removeDocument(SrcML f_srcml) {}
> So if I understand that correctly the AnalyzerPlatform still only
> has a execute() method without parameters, but implicitly calls
> the plugin with execute(getDocuments()) ?
exactly. Do you see any problems with this?

>> The advantage is, that you can add all your files you want to be
>> analyzed and then run numerous analyzes on it, with just set the new
>> plugin each time.
> Sounds good. Although you could do the same for the View too. The
> Vector of SrcML documents has to be created 'somewhere'. In your
> case the AnalyzerPlatform takes care of it and in the case of the
> ViewPlatform the callee would have to use the same Vector for every
> chosen ViewPlugin. But from a design point of view your solution
> looks better to me as it's emphasizing the platform concept more
> clearly.
ok, but this could take 'til wednesday.

 > Leif

Re: Fwd: Re: [SrcML] Java 1.5 update

[Frank R. <fra...@in...>]

On Sat, May 28, 2005 at 12:08:35PM +0200, Dennis Waldherr wrote:
> >Well the List interface specifies addAll to be "|*addAll 
> ><http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection 
> ><http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? 
> >extends E <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> 
> >c)|" in which the "second" E (being '?') may differ as long as it's 
> >subtype of the first E.
> 
> O o
> 
> Ok this link garbage wasn't meant to be sent... actually I wanted to write
> addAll(<? extends Collection>)
> 
> (good work Thunderbird :/ )
> -
> Dennis

That's why we have you on the project :).. I found the main problem of
this kind to occur in the PrintSelectionJava plugin with a return type
of Vector<Vector<SrcMLElement>> which I have now changed to use
Vector<Vector<? extends SrcMLElement>>. This needed a few more changes,
but works out great when adding List<Method> or similar objects.
Thanks for the pointer. We'll still have to make some more modifications
to the existing source (f.ex. changing those Vectors to Lists), but so
far the addition of generics seems to be rather unproblematic and the
new for loops alone justify the switch.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

If you want truly to understand something,
try to change it. (Kurt Lewin)

Re: Fwd: Re: [SrcML] Java 1.5 update

[Dennis W. <den...@in...>]

Dennis Waldherr wrote:

> Frank Raiser wrote:
>
>> As I said we're compiling with -Xlint:unchecked now _and_ I've
>> rewritten big parts of the code to minimize the amount of warnings
>> by adding proper generics. This means there are no more occurences
>> of List or Vector without a generic type specification added to it.
>> As for my example method it was an invention only and I don't know
>> if it exists as such in the source code (so it could very well be
>> List<Method> by now). However that is not the point I'm trying to get 
>> across.
>> The main problem is that it is no longer List.addAll(Collection c),
>> but now we are implicitly calling List<E>.addAll(Collection<E> c) and
>> we're running into the above 'problem' whenever the first and second E
>> differ.
>>
>>  
>>
> Well the List interface specifies addAll to be "|*addAll 
> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection 
> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? 
> extends E 
> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> c)|" in 
> which the "second" E (being '?') may differ as long as it's subtype of 
> the first E.

O o

Ok this link garbage wasn't meant to be sent... actually I wanted to write
addAll(<? extends Collection>)

(good work Thunderbird :/ )
-
Dennis

Re: Fwd: Re: [SrcML] Java 1.5 update

[Dennis W. <den...@in...>]

Frank Raiser wrote:

>As I said we're compiling with -Xlint:unchecked now _and_ I've
>rewritten big parts of the code to minimize the amount of warnings
>by adding proper generics. This means there are no more occurences
>of List or Vector without a generic type specification added to it.
>As for my example method it was an invention only and I don't know
>if it exists as such in the source code (so it could very well be
>List<Method> by now). 
>However that is not the point I'm trying to get across.
>The main problem is that it is no longer List.addAll(Collection c),
>but now we are implicitly calling List<E>.addAll(Collection<E> c) and
>we're running into the above 'problem' whenever the first and second E
>differ.
>
>  
>
Well the List interface specifies addAll to be "|*addAll 
<http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html#addAll%28java.util.Collection%29>*(Collection 
<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html><? 
extends E 
<http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html>> c)|" in 
which the "second" E (being '?') may differ as long as it's subtype of 
the first E.

-
Dennis

Fwd: Re: [SrcML] Java 1.5 update

[Frank R. <fra...@in...>]

I forward this to the list, as I suspect it was accidentally sent to
me only:

----- Forwarded message from Dennis Waldherr <den...@in...> -----

Frank Raiser wrote:

>All compiles are now done with -Xlint:unchecked. There are a few
>places where the generics aren't as nice as I'd like them to be.
>Everywhere where we interact with other libraries not using generics
>we obviously get into trouble. There's still a compiler warning in
>the srcml module for the line elements().add(i, e) which involves
>a dom4j method. Maybe Dennis can take a look at that, as I haven't
>found a way to silence the compiler there. I've not added this
>compiler option to the parser-java's build.xml as the generated
>antlr sourcecode is giving a myriad of errors then. We will still
>have to wait for a 1.5 version of antlr for that.
>
> 
>
No idea on the elements().add(i,e) thing yet.

>Vector<SrcMLElement> v = new Vector<SrcMLElement>
>for (Method m : getMethods()) v.add(m);
>
>This basically means 'casting' a Vector<Method> to a 
>Vector<SrcMLElement>. If someone knows a more elegant way to solve
>the above problem please let me know.
>
> 
>
v.addAll(getMethods())
should work. My getMethods implementation still returns a normal List 
(and I'd prefer it to return a List<Method> lateron and not a 
Vector<Method>)

-
Dennis
----- End forwarded message -----

As I said we're compiling with -Xlint:unchecked now _and_ I've
rewritten big parts of the code to minimize the amount of warnings
by adding proper generics. This means there are no more occurences
of List or Vector without a generic type specification added to it.
As for my example method it was an invention only and I don't know
if it exists as such in the source code (so it could very well be
List<Method> by now). 
However that is not the point I'm trying to get across.
The main problem is that it is no longer List.addAll(Collection c),
but now we are implicitly calling List<E>.addAll(Collection<E> c) and
we're running into the above 'problem' whenever the first and second E
differ.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Software suppliers are trying to make their software packages more
user-friendly. Their best approach, so far, has been to take all the old
brochures, and stamp the words, user-friendly on the cover. (Bill Gates)

Re: [SrcML] static analyzis

[Frank R. <fra...@in...>]

On Tue, May 24, 2005 at 09:22:16PM +0200, Leif Bladt wrote:
> The analyzer plugins can handle more than one SrcML document now. 
> Therefore I changed the execute method from:
>     public abstract Vector execute(SrcML f_srcml) throws 
> PluginException;
> to
>     public abstract Vector execute(Vector f_docs) throws 
> PluginException;

You can change that into 
public abstract Vector<AnalyzerResult> execute(
    Vector<SrcML> f_docs) throws PluginException
now that we 'support' java 1.5 to increase the type safety.
(same for the methods below)

> I also changed the Analyzer Platform, but I didn't adopted the way the 
> View Platform handles this. Instead I will use a Vector with SrcML 
> documents in it. To manage the Vector there are 4 methods:
>     public Vector addDocument(SrcML f_srcml) {}
>     public Vector getDocuments() {}
>     public void removeAllDocuments() {}
>     public Vector removeDocument(SrcML f_srcml) {}

So if I understand that correctly the AnalyzerPlatform still only
has a execute() method without parameters, but implicitly calls
the plugin with execute(getDocuments()) ?

> The advantage is, that you can add all your files you want to be 
> analyzed and then run numerous analyzes on it, with just set the new 
> plugin each time.
> 
> As always, tell me what you think about it!

Sounds good. Although you could do the same for the View too. The
Vector of SrcML documents has to be created 'somewhere'. In your
case the AnalyzerPlatform takes care of it and in the case of the
ViewPlatform the callee would have to use the same Vector for every
chosen ViewPlugin. But from a design point of view your solution
looks better to me as it's emphasizing the platform concept more
clearly.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

[SrcML] Java 1.5 update

[Frank R. <fra...@in...>]

As we decided to use java 1.5 features from now on I rewrote
most parts of the existing code to use generics where applicable.
Please update all your CVS modules and in case of conflicts use
your own code and just add the generic part to it.
(And I don't think I have to mention that from now on using a
java 1.5 compiler would be a good idea)

All compiles are now done with -Xlint:unchecked. There are a few
places where the generics aren't as nice as I'd like them to be.
Everywhere where we interact with other libraries not using generics
we obviously get into trouble. There's still a compiler warning in
the srcml module for the line elements().add(i, e) which involves
a dom4j method. Maybe Dennis can take a look at that, as I haven't
found a way to silence the compiler there. I've not added this
compiler option to the parser-java's build.xml as the generated
antlr sourcecode is giving a myriad of errors then. We will still
have to wait for a 1.5 version of antlr for that.

I've also come to realize first hand what Prof. Heinlein meant about
the existing generics not allowing polymorphic use. As we want to get
the most benefits from the generic typing we have methods like:
Vector<Method> getMethods()
which is nice, as it is guaranteeing us that all elements will be
instanceof Method. However we often want to use this result Vector
and add it to a Vector<SrcMLElement>. This doesn't work however (as
we would be working on the original Vector<Method> and could add
SrcMLElement instances to it like that). For the same reason it
doesn't work with a Vector<? extends SrcMLElement> either. For now
I've worked around this problem with the following code template:

Vector<SrcMLElement> v = new Vector<SrcMLElement>
for (Method m : getMethods()) v.add(m);

This basically means 'casting' a Vector<Method> to a 
Vector<SrcMLElement>. If someone knows a more elegant way to solve
the above problem please let me know.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

A complex system that works is invariably found to have evolved from a simple
system that worked. (John Gall)

[SrcML] Java 1.5 code now ok

[Frank R. <fra...@in...>]

We just decided that it is now acceptable to use Java 1.5 code for the
project. This means we will be unable to perform unit tests and parsing
the sourcecode files of the project. However parsing the project's
sourcefiles is currently most important for the developing of the 1.5
parser which is (or rather should be) capable of parsing it. As the parser
will hopefully be available within a week or two there is no more reason
not to take advantage of 1.5. 
As for those developers interested in getting SrcML documents there's
of course still the possibility to convert your own selected 1.3 sourcecodes.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Clarke's First Law:
When a distinguished but elderly scientist states that something is possible
he is almost certainly right. When he states that something is impossible,
he is very probably wrong. (Arthur C Clarke)

[SrcML] static analyzis

[Leif B. <lei...@in...>]

The analyzer plugins can handle more than one SrcML document now. 
Therefore I changed the execute method from:
     public abstract Vector execute(SrcML f_srcml) throws 
PluginException;
to
     public abstract Vector execute(Vector f_docs) throws 
PluginException;

I also changed the Analyzer Platform, but I didn't adopted the way the 
View Platform handles this. Instead I will use a Vector with SrcML 
documents in it. To manage the Vector there are 4 methods:
     public Vector addDocument(SrcML f_srcml) {}
     public Vector getDocuments() {}
     public void removeAllDocuments() {}
     public Vector removeDocument(SrcML f_srcml) {}

The advantage is, that you can add all your files you want to be 
analyzed and then run numerous analyzes on it, with just set the new 
plugin each time.

As always, tell me what you think about it!

Leif

[SrcML] Summary of remaining tasks

[Frank R. <fra...@in...>]

This is just a quick mail about the remaining tasks we discussed today.
As the SourceForge statistics system is back online I decided to create
proper project tasks for those as we need the activity boost considering
we're only ranked project #11697 for now ;)

Sorry for the long links. I'll only present a short summary of the tasks
here for reference, a more complete description is found on the SF pages
for these tasks:

#1: (assigned to Dennis)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115884&group_id=105448&group_project_id=36654

Extending the configuration capabilities for plugins (toString method,
adding configuration information to plugin.xml and making it retrievable
through PluginConfig)

#2: (assigned to Frank)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115836&group_id=105448&group_project_id=35838

Update the current java parser to fully support java 1.5 features.

#3: (assigned to Simon, Frank)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115885&group_id=105448&group_project_id=35838

Adjust the ViewPlatform and API to the changes implied through the new
1.5 java parser (getCommonType, support for printing the new tags, etc)

#4: (assigned to Simon, Frank, Leif - not assigned on SF to Leif due to 
    missing account name)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115886&group_id=105448&group_project_id=35841

Implementing an ant task for the AnalyzerPlatform with support for
explicitly choosing plugins and configuring them. Add understandable
output to the AnalyzerPlatform - which requires line number information
from the ViewPlatform.

#5: (assigned to Matthias - not assigned on SF due to missing account name)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115888&group_id=105448&group_project_id=43047

Developing a tree grammar for the python parser from the existing python grammar.

#6: (assigned to Claudia - not assigned on SF due to missing account name)
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=115889&group_id=105448&group_project_id=37242

Research how to convert SrcML to UML (visio, XMI,...) and check if the conversion
process can be integrated into the SrcML framework as a view plugin.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Pesticide Paradox:
Every method you use to prevent or find bugs leaves a residue of subtler bugs
against which those methods are ineffectual. (Bruce Beizer)

[SrcML] Re: UML2.0 representition

[Claudia L. <C.S...@we...>]

Frank Raiser <fra...@in...> schrieb am 20.05.05 13:30:14:

> On Fri, May 20, 2005 at 10:06:58AM +0200, Claudia Lang wrote:
> > as I mentioned in the latest meeting I'm going to implement a project representing XML-Code in UML2.0 The chosen language for this project is Java and the name of the project XUML. 
> 
> After a quick google for XUML I think you might want to use another name, as
> XUML is already heavily used for eXecutable UML (there also seems to be a book
> available on this subject).
I know that it is already in use but just with a little x: xUML. Well, ok before we start a big discussion I will change the name. 

> > - template class: exists in Java since version 1.5 but SrcML parses Java version 1.4.2
> 
> Actually only 1.3, but I'm currently working on a parser for version 1.5 which
> should become useable within a few weeks. (Only annotations and enums are currently
> missing).
Yes, you mentioned this. Ok then template classes will be realized in this project.

> > - association and association class
> 
> What are you reasons for not including associations? Simon and me thought that it
> should be possible to add aggregation relations, but we haven't yet thought about
> all eventualities of course.
I'm thinking about.

> > - stereotype
> 
> Could you please explain what this means in the context of class diagrams?
Stereotypes are (partly user-defined) elements categorizing classes. If you desing e.g. a class and you want to note that its instances has to be saved persistent  you write the stereotype "persistent" over the name of the class. You see that stereotypes don't belong to those parts of features who can be implemented in sourcecode.


 

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

Re: [SrcML] UML2.0 representition

[Leif B. <lei...@in...>]

> as I mentioned in the latest meeting I'm going to implement a project 
> representing XML-Code in UML2.0 The chosen language for this project 
> is Java and the name of the project XUML.
>
> The XML-Code which shall be represented in UML2.0 is handed over to 
> the software project by executing it. The user can start the project 
> by the BASH typing the name of the project followed by the XML-Files. 
> I know so far SrcML is running just under Linux. Linux users don't 
> like GUIs so much. Nevertheless I will also implement a  simple one. 
> Maybe some day there will be a Windows version of SrcML. In this GUI 
> the files can be chosen by clicking on them.
So XUML will be a stand-alone-program which processes SrcML documents? 
What's about the idea to make this a view plugin? I would favor this 
plugin, because your not fixed to a special program to view UML 
diagrams of your sourcecode. Instead every "end-user-tool", which uses 
SrcML (I hope everbody know's what I mean), i.e. the forthcoming 
Eclipse plugin, can make use of it.

Leif

Re: [SrcML] UML2.0 representition

[Frank R. <fra...@in...>]

On Fri, May 20, 2005 at 10:06:58AM +0200, Claudia Lang wrote:
> as I mentioned in the latest meeting I'm going to implement a project representing XML-Code in UML2.0 The chosen language for this project is Java and the name of the project XUML. 

After a quick google for XUML I think you might want to use another name, as
XUML is already heavily used for eXecutable UML (there also seems to be a book
available on this subject).

> The XML-Code which shall be represented in UML2.0 is handed over to the software project by executing it. The user can start the project by the BASH typing the name of the project followed by the XML-Files. I know so far SrcML is running just under Linux. Linux users don't like GUIs so much. Nevertheless I will also implement a  simple one. Maybe some day there will be a Windows version of SrcML. In this GUI the files can be chosen by clicking on them. 

SrcML is written in Java and runs on all platforms which support Java. This includes
Windows, but of course it's a little bit harder to setup a development environment.

> UML2.0 includes 13 different kind of diagrams. For it's to much for a single person to implement a project supporting all of these I concentrate on one diagram: the ClassDiagram. It is seen as the foundation on which all the other diagrams - behavior diagrams and the rest of the structured diagrams - build.
> 
> It is not possible to realize all of the notations which can be uses in ClassDiagrams in Java and thus in SML. So the followed notations will not be represented by XUML:
> 
> - template class: exists in Java since version 1.5 but SrcML parses Java version 1.4.2

Actually only 1.3, but I'm currently working on a parser for version 1.5 which
should become useable within a few weeks. (Only annotations and enums are currently
missing).

> - association and association class

What are you reasons for not including associations? Simon and me thought that it
should be possible to add aggregation relations, but we haven't yet thought about
all eventualities of course.

> - stereotype

Could you please explain what this means in the context of class diagrams?

> Before I can go on and finish the requirement phase I need some answers on the following questions:
> 
> - which kind of classes doews SrcML realize? Embedded abstract classes and also interfaces? How does SrcML handles the import of packages? Does SrcML realize user specified types?

If you mean 'embedded' as in inner classes, then yes. Abstract classes are supported
too, and also interfaces. Package import is showing up in SrcML as something like this:
<import package="java.util.Vector"/>

SrcML does not (yet :) have a type inference engine. But we do have type information
at those points where the original program's source code has explicit types. This means
you can get the types for variables and parameters and the like, but you can not find
out the result type of an expression. But I think for the purpose of generating a class
diagram the existing type information should be sufficient.

> - maybe somebody can send me a SrcML document as an example?

You should have created one for yourself as part of the 'zeroth' practice and
if you didn't do so yet I suggest you set up a proper environment where
you are able to parse java files into SrcML files. You will definitely need
to parse several files during the course of this practical in order to test
your application.
If you have any problems with the installation just show up in the linux pool
and ask us.

> - so far it is also not clears whether the ClassDiagram shall be saved as a Visio or an XMI file. I've googled for some interresting document telling more about XMI but without any success. Also the book shops have no books dealing with XMI. Maybe you can recommend a link or a book?

Here's a rather informal introduction:
http://www.jeckle.de/xmi.htm

And here's the formal specification of XMI 2.0:
http://www.omg.org/cgi-bin/doc?formal/05-05-01

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

In the world of systems design, programs and data are the scissor blades
working together to form the broader class -- software. Lacking either blade,
computers couldn't cut through problems -- yet for many people, software is 
synonymous with programs. (Tom Gilb)

[SrcML] UML2.0 representition

[Claudia L. <C.S...@we...>]

Hello,

as I mentioned in the latest meeting I'm going to implement a project representing XML-Code in UML2.0 The chosen language for this project is Java and the name of the project XUML. 

The XML-Code which shall be represented in UML2.0 is handed over to the software project by executing it. The user can start the project by the BASH typing the name of the project followed by the XML-Files. I know so far SrcML is running just under Linux. Linux users don't like GUIs so much. Nevertheless I will also implement a  simple one. Maybe some day there will be a Windows version of SrcML. In this GUI the files can be chosen by clicking on them. 

UML2.0 includes 13 different kind of diagrams. For it's to much for a single person to implement a project supporting all of these I concentrate on one diagram: the ClassDiagram. It is seen as the foundation on which all the other diagrams - behavior diagrams and the rest of the structured diagrams - build.

It is not possible to realize all of the notations which can be uses in ClassDiagrams in Java and thus in SML. So the followed notations will not be represented by XUML:

- template class: exists in Java since version 1.5 but SrcML parses Java version 1.4.2
- association and association class
- stereotype
- note: though it's possible to start a comment in Java I decided not to consider this because it is normally quite long and will restricht the clearness of the ClassDiagram

Before I can go on and finish the requirement phase I need some answers on the following questions:

- which kind of classes doews SrcML realize? Embedded abstract classes and also interfaces? How does SrcML handles the import of packages? Does SrcML realize user specified types?

- maybe somebody can send me a SrcML document as an example?

- so far it is also not clears whether the ClassDiagram shall be saved as a Visio or an XMI file. I've googled for some interresting document telling more about XMI but without any success. Also the book shops have no books dealing with XMI. Maybe you can recommend a link or a book?

That's all so far.

Bye
Claudia
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

[SrcML] Method.java

[Frank R. <fra...@in...>]

This is primarily for Dennis as he's working on the API convenience methods.
I've just taken a quick look on the CVS commits and seen the following for
de.srcml.dom.Method.setConstructor:

        else
            {
                Element e = new Type();
!               e.addAttribute(Type.ATTR_NAME, Type.TYPE_VOID);
!               elements().add(0, e);
            }

Please make sure your changes adhere to the DTD/Schema ! The return type
of a method can not just be added as the last child. See srcml/srcml.xsd
and especially Tmethod (lines 381ff) for that.

It would be nice if you could add unit tests for these methods too (which
should catch those errors, as the least thing to test for is adherence to
the Schema after the changes.) I think I will import the unittests module
for this into CVS tomorrow.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

I think it is inevitable that people program poorly.
Training will not substantially help matters.
We have to learn to live with it. (Alan Perlis)

Re: [SrcML] SrcML DOM: Unit

[Frank R. <fra...@in...>]

On Wed, May 18, 2005 at 10:59:53AM +0200, Leif Bladt wrote:
> Can anybody explain me this constant variables (found in 
> de.srcml.dom.Unit.java)? I thought I could use them to get the 
> corresponding filename of a unit, at least the comments promise me 
> this.

Sure.. here we go:

> /** The programming language of this SrcML Unit */
> public final static String ATTR_LANGUAGE = "language";

This is one of the language strings defined in de.srcml.language.Language.
(right now chances are pretty high it is de.srcml.language.Language.LANG_JAVA)

> /** The filename of this SrcML unit */
> public final static String ATTR_FILENAME = "filename";

This is the filename which was given to the parser when the SrcML file was
created (see de.srcml.parser.Parser.setFilename) and represents the name
of the original source code file.

> /** The author of this SrcML unit */
> public final static String ATTR_AUTHOR = "author";

This attribute isn't very well supported yet. Currently the java parser
plugin sets the currently logged in username as author.


Note that all these constants only define the name of the attribute in the
<unit> tag. So for ATTR_FILENAME this means we get: <unit filename="...">
and you get the actual filename (the '...') using something like this:
unit_instance.getAttribute(Unit.ATTR_FILENAME)

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

You can either have software quality or you can have pointer arithmetic,
but you cannot have both at the same time. (Bertrand Meyer)

[SrcML] SrcML DOM: Unit

[Leif B. <lei...@in...>]

Can anybody explain me this constant variables (found in 
de.srcml.dom.Unit.java)? I thought I could use them to get the 
corresponding filename of a unit, at least the comments promise me 
this.

/** The programming language of this SrcML Unit */
public final static String ATTR_LANGUAGE = "language";
/** The filename of this SrcML unit */
public final static String ATTR_FILENAME = "filename";
/** The author of this SrcML unit */
public final static String ATTR_AUTHOR = "author";



 > Leif Bladt

[SrcML] CVS restructuring

[Frank R. <fra...@in...>]

Hello everybody,

as mentioned during the meeting Dennis and me have been restructuring
the CVS into a new (smaller) set of modules. Please update your
installations to the new CVS modules described below and especially
take care you don't get a mixture of old and new modules (if you
haven't made any changes to the source code yet it's safest to just
delete the old modules).

These are the new modules now:

srcml - This module contains a de/srcml/* file hierarchy in which all
        the common base source for the SrcML Framework is located. This
        includes the API and the various platforms.

parser-java - The plugin for the java parser

views - The collection of the various view plugins

unittests - All unit tests have been merged into this module. The build.xml
            file will have to be rewritten to directly call certain tests to
            avoid testing the whole framework each time. (Currently this module
            isn't in CVS yet, as the Linux pool is still missing junit support
            for ant and we couldn't test if it works yet. This will be done when
            the junit support is back of course).

Note that the parser-java and views CVS modules are still the same modules and
if you're not doing a fresh checkout you should take care to use 'cvs up -d'
instead.

Also delete the srcml-*.jar files in your jars/ directory which represented the
old modules and might lead to inconsistencies if they co-exist with the new
srcml.jar file.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

The science of today is the technology of tomorrow. (Edward Teller)

Re: [SrcML] Static source code analysis with SrcML

[Frank R. <fra...@in...>]

On Sat, May 07, 2005 at 05:41:42PM +0200, Leif Bladt wrote:
> I wrote a little document about "Static source code analysis with 
> SrcML". It describes what I want to do in my practical :-) I cut out 
> the part about "Available software", which isn't ready to be published 
> yet.
> 
> http://www.bladt.info/leif/srcml/static_analyze.pdf
> 
> Please feel free to tell me what you think about (criticism, proposals, 
> etc.).

Just a few remarks:

- "The API should provide a basic set of plug-ins for the Analyze Platform"
  Why the API? The API can be considered to be only a collection of helper
  classes and methods for writing programs which use SrcML. It doesn't
  provide any plugins. A plugin can be provided by any third party too.

- You grouped them by subject, but what I'm missing is how the actual
  interface between Analyze Platform and the plugin looks like. Which
  methods does every plugin need to perform its work when run through
  the Analyze Platform? Preferably we don't want to have to call a special
  method for each plugin. To see what I mean think of a third party plugin,
  and how the Analyze Platform will be able to handle it without any
  modifications needed even though you know nothing about what the plugin
  actually does. (We also need a way for the results to be handled)

- I don't quite see the difference between the EmptyStatementNotInLoop and
  the EmptyStructures. Besides the loop exception the only empty statement
  not involved with a structure I can think of would be a NOP command.

- OverrideEqualsHashcode and SuspiciousHashcode are explained a bit too
  shortly. Which two methdos are you thinking of in the first place? And
  what's a hashcode method anyways?

- For 3.2.2 (Javadoc) I was thinking of a more generic support for Javadoc
  (or basically anything like it, as it could as well be used in other 
  languages) within the API. At least something like the dissecting of the
  comment into a description part and the individual "@name text" pairs
  should be available there.

- We already thought about something like NamingConvention too. It would be
  nice if you were able to specify what exactly the naming convention is,
  which was the major problem for implementing that earlier. How can you
  keep the plugin generic, yet give it information about the naming convention
  without knowing to call a special method. And we especially don't want that
  call to happen inside the Analyze Platform.
  But with the new plugin system this problem has been solved on the way.
  The plugin itself defines a naming convention and a company wanting to
  enforce their own naming conventions can simply write a plugin which
  extends from the original one and only modifies the relevant parts to match
  their naming conventions.

- What does SuspiciousEquals do?

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

All sorts of computer errors are now turning up. You'd be surprised to know 
the number of doctors who claim they are treating pregnant men. (Isaac Asimov)

[SrcML] Static source code analysis with SrcML

[Leif B. <lei...@in...>]

Hi,
I wrote a little document about "Static source code analysis with 
SrcML". It describes what I want to do in my practical :-) I cut out 
the part about "Available software", which isn't ready to be published 
yet.

http://www.bladt.info/leif/srcml/static_analyze.pdf

Please feel free to tell me what you think about (criticism, proposals, 
etc.).


Leif Bladt

Re: [SrcML] static source code analyzis

[Frank R. <fra...@in...>]

On Wed, May 04, 2005 at 05:31:50PM +0200, Leif Bladt wrote:
> Hmm, I think the term "plug-in" is a little confusing. With plug-ins I 
> mean the plug-ins for the "analyzer platform", which are accesible via 
> the API.

Or rather the PluginManager residing in the config package.

> To use them, we need a "tool", which can be either a single 
> java program or an Eclipse plug-in.

Or both.

> >Ant plugin? Ant is a build platform which is comparable to GNU make.
> >I don't think it makes sense to plug into that.
> What I meant was to create an Ant task to call the analyzer tool 
> (written in java for example). Just like you execute the JUnit tests. 
> For me it makes sense, because you could run your JUnit tests with 'ant 
> test' and your static analysis with 'ant analyze'. What do you think?

Ah ok. I misunderstood you there. Yes that would be a possibility too.
I generally believe that there are a lot of different places where the
analyses can actually be applied then. But indeed the combination of
JUnit tests and analyses through ant sounds like a good idea.

> I would appreciate an Eclipse plug-in for the SrcML project, too. And 
> the analyze functions should be part of it. But I think this whole 
> plug-in is work for more than one person :-)

Ok done :)
Simon wanted to work on the Eclipse plugin anyways, so you two could
adjust your schedules so that you can get the basic version of an
analyzer platform done while Simon prepares the integration of SrcML
into Eclipse. You could then flesh out the details of the Eclipse plugin
together.

As for the analyze functions to be part of the Eclipse plugin I'm not sure
I understood you correctly. The goal of the Eclipse plugin should be calling
the SrcML Framework. And the various possible analyses should be available
outside of Eclipse as well (f.ex. to be used in an ant task). But of course
the Eclipse plugin (or plugins.. I'm not yet sure about that) will have to
be able to access the analyzer functions in some way (as well as display the
results).

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

If you torture data sufficiently, it will confess to almost anything.
(Fred Menger)

Re: [SrcML] static source code analyzis

[Leif B. <lei...@ma...>]

Hmm, I think the term "plug-in" is a little confusing. With plug-ins I 
mean the plug-ins for the "analyzer platform", which are accesible via 
the API. To use them, we need a "tool", which can be either a single 
java program or an Eclipse plug-in.

> Ant plugin? Ant is a build platform which is comparable to GNU make.
> I don't think it makes sense to plug into that.
What I meant was to create an Ant task to call the analyzer tool 
(written in java for example). Just like you execute the JUnit tests. 
For me it makes sense, because you could run your JUnit tests with 'ant 
test' and your static analysis with 'ant analyze'. What do you think?

> As for an Eclipse plugin this has been planned for a while now. We can
> offer you a book on the subject (Gamma et.al: Contributing to Eclipse)
> in which you can read up on how plugins for Eclipse are created. 
> Basically
> it's a very simple process of writing a special XML file for your 
> plugin.

> The statical analyses per se don't really require Eclipse, so the 
> Eclipse
> integration would rather mean making the complete SrcML Framework 
> available
> within Eclipse (i.e. allowing the current file/project to be parsed). 
> We'll
> have to think of how to get the plugins done easily and still be able 
> to
> run the rest without Eclipse as well.
I would appreciate an Eclipse plug-in for the SrcML project, too. And 
the analyze functions should be part of it. But I think this whole 
plug-in is work for more than one person :-)

Leif Bladt