srcml-discussion — General discussions about the SrcML framework

[SrcML] Developer jobs posted

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

Hi everyone,

Considering the recently lacking amount of work on SrcML by the current
team I decided to post developer requests on SourceForge. (and because I
always wanted to know whether that really works ;)

This page contains a listing of the jobs if anyone's interested:
https://sourceforge.net/people/?group_id=105448

PS: If anyone on this list currently has some spare time there is some
interesting work remaining in the API. The de.srcml.dom.* hierarchy of
classes is currently being extended to include de.srcml.dom.java.*
classes which the JavaTransformer is going to use. Due to this there is
a need for a Factory class creating instances of the respective DOM
classes. More details about this can be found on the ToDo page on the
SrcML Wiki.

PPS: I began work on structuring the classes in de.srcml.dom through
interfaces like ISupportsModifiers (work is not yet in CVS.) There's
also a lot of work remaining here in categorizing the common semantics
for which such interfaces are suitable and implementing those.

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

100 pages of comments will not make a
poorly written page of code not suck. (Robert Mollitor)

[SrcML] SrcML 0.2.2 Released

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

= Changes for release 0.2.2 =

== major changes ==
 * added `de.srcml.dom.event.*` for change notifications
 * new ViewPlatform implementation

== minor changes ==
 * small fixes in view plugins
 * `main` method for AnalyzerPlatform
 * support for printing line numbers with `ViewJava` plugin

== SrcML schema changes ==
 * only one 'throws' for methods which therefore contains multiple thrown 'type's
 * added 'annotation's for methods
 * switched 'parameter_type_bound' children to 'type' from 'type_element', as multiple 'type_element's were ambiguous.

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

Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live. (Martin Golding)

Fwd: Re: [SrcML] a little bug

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

----- Forwarded message from Icaro <ic...@gm...> -----

Date: Sun, 11 Sep 2005 14:40:41 +0200
From: Icaro <ic...@gm...>
Subject: Re: [SrcML] a little bug

This is just my case. I am writing, for my degree thesis, a fine grained 
Configuration Management System that can operate on methods level and 
not on file. 

IMHO what distinguishes SrcML from other projects like Jezix or JavaML 
is proper the fact that it doesn't focus on a specific programming 
language (at least in the intentions). For which would surely be 
preferable in my case (the CMS) an abstract approach to the different 
types of sources. 

[...]

Python was only a proposal suited for my needs. Perhaps it would be 
simpler to write a parser for a more Java-like language.  
Is there a guide, a tutorial or something else, that describe how to add 
a parser to SrcML?

http://icaro.blogspot.com
----- End forwarded message -----

This is indeed one of the (supposed) strengths of SrcML. One of the
ideas we had for interesting applications was a patch to CVS/subversion
to allow for actually diff not line-based, but semantic based by storing
SrcML only. It would also allow you whole new queries like 'when was
this method changed the last time'.. well there are uncountable
possibilities.

As for python we have not decided that this has to be the next language.
Only that said student wanted to do a parser for it. Basically we'd like
to restrict it to OO languages right now, because if you include _all_
languages there is no more common denominator at all. With OO languages
you have at least several things like classes, methods, variables.. in
common (with slight - queryable - differences such as multiple
inheritence, support for interfaces etc).

There is no explicit description for how to add a parser to SrcML, as
each parser is contained in its own plugin. This gives the developer of
the parser a huge amount of freedom. So all that's required is one class
which is a subclass of de.srcml.parser.ParserPlugin. Input can be
generally retrieved through de.srcml.util.Input and output (a string
containing the parsed SrcML document) should go to de.srcml.util.Output.

That's all there is to it except if you want to get a little fancier and
support incremental parsing for smaller constructs. There are a few
methods for that defined in the ParserPlugin class which you can
overwrite to support that (but it's not required, as the default
implementation will throw an UnsupportedOperationException).

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

Truth is a good dog; but always beware of barking too close to the heels
of an error, lest you get your brains kicked out. (Samuel T Coleridge)

[SrcML] new ViewPlatform in CVS

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

The new ViewPlatform (as discussed earlier on this list) is now in CVS.

If you have a few minutes to spare please try it as it will certainly
have a few glitches left. The new ViewJava plugin is now oriented at the
SUN Java Coding Conventions. Of course not all points mentioned in the
conventions are supported, but the code should be relatively close.

The old plugins are still in CVS, but are commented out in the ant build
file, as they will not work with the new platform anymore.

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

All good work is done in defiance of management. (Bob Woodward)

Re: [SrcML] a little bug

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

On Sat, Sep 10, 2005 at 05:41:01PM +0200, Icaro wrote:
> Frank Raiser ha scritto:
> >As it looks like right now we still have at least 3 active developers.
> >Though they are not as active as they would be in a perfect world I
> >think it should be enough to get some more interesting things done :)
> > 
> >
> 
> And I hope this. I see a lot of potentialities in SrcML if it will be 
> amplified. 

So do we all, but all that potential doesn't come from nothing. Right
now most people have problems to see this potential and therefore the
nubmer of developers is very low right now. I can't even blame anyone
for that, as you have to realize that we are basically working on a
meta-meta-language level here. SrcML is very powerful for developing
applications which in turn work with sourcecode again. But this means
that your average developer who just wants to use the final application
for his work will not be interested too much. In fact she should not
even need to know SrcML is involved at all for most tools.

> Particularly it would be beautiful to be able to have a support for 
> another language (python?)

We did have a python parser started during last semester's practical
course, however the student responsible for it left the project (due to
not needing the course anymore for his studying).
I personally don't have enough time right now to develop a second
parser, as most of my work will go into the UML support for SrcML as
part of my diploma thesis. And unfortunately I don't believe any of
the other developers is interested in writing a parser.

> >PS: Starting with srcml-0.2.1 all platforms are accessible through Java
> >directly and the bin module is therefore considered deprecated. See the
> >Introduction page on the Wiki on srcml.de for a few examples. Quick
> >start: "java de.srcml.parser.Parser" should work similar to calling
> >"jython parse.py" (takes similar parameters, etc)
> >
> I believe it's correct to directly have the same functionalities 
> accessible from SrCML, but I dislike to learn however that the jython 
> scripts  won't be adjourned anymore. 
> I find it a simple and immediate way to learn the API.

The jython scripts are basically just very simple wrappers which parse
the commandline arguments and just call the corresponding platform
accordingly. There is next to no logic contained in these scripts.
However that we consider this bin module deprecated does not mean that
it's useless or that you can't use jython with SrcML anymore. The
scripts will still be in CVS, we will just not advertize them any
further. If you still want to use those scripts the only problem might
occur with changes in the platforms (like the new ViewPlatform[1] will
break view.py). But you could easily adjust those scripts with minimal
knowledge of jython and the platform. Simply calling the platform once
with --help gives you the options it takes and the jython script just
needs to take the same options again.
If you experience any of these troubles feel free to send me a patch,
however I won't invest too much time myself into keeping those scripts
up to date (as mentioned earlier there is still a lot to do and time is
always short).


[1] Watch out for the new ViewPlatform to be announced on this list
later today ;)

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

Manuals just slow you down and make you feel stupid. The directions are too
slow, too detailed, and use too much abstract, arcane or academic language --
like boot up instead of turn on the red switch in the back. (Neil Fiore)

Re: [SrcML] a little bug

[Icaro <ic...@gm...>]

Frank Raiser ha scritto:

>On Fri, Sep 02, 2005 at 04:29:32PM +0200, Icaro wrote:
>  
>
>>Hi
>>first of all I want to tell you that I find SrcMl very interesting and I 
>>hope that its development actively will continue in the future
>>    
>>
>
>As it looks like right now we still have at least 3 active developers.
>Though they are not as active as they would be in a perfect world I
>think it should be enough to get some more interesting things done :)
>  
>

And I hope this. I see a lot of potentialities in SrcML if it will be 
amplified. 
Particularly it would be beautiful to be able to have a support for 
another language (python?)


>PS: Starting with srcml-0.2.1 all platforms are accessible through Java
>directly and the bin module is therefore considered deprecated. See the
>Introduction page on the Wiki on srcml.de for a few examples. Quick
>start: "java de.srcml.parser.Parser" should work similar to calling
>"jython parse.py" (takes similar parameters, etc)
>
I believe it's correct to directly have the same functionalities 
accessible from SrCML, but I dislike to learn however that the jython 
scripts  won't be adjourned anymore. 
I find it a simple and immediate way to learn the API.

-- 
Domenico (aka ^I^caro)

http://preponderante.splinder.com  <-- personale
http://icaro.blogspot.com          <-- perhaps technical
          
     ~~~~     "Dove mai andiamo?"......"Sempre a casa"....   ~~~~

[SrcML] next steps

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

Hello everyone,

I think we should clarify what the next steps of the SrcML development
should be. As we're no longer having any meetings to keep each other
updated on what's going on we will have to rely more intensly on this
mailinglist and the wiki.

I suggest that we extend the ToDo page to include a table of what
everyone's working on and more important when it is expected to be
finished.
I have already added that table and would like you to fill it out with
what you're working on. Note that the expected finishing time is no hard
deadline of course, but it should function as a means of giving others
an idea when the new code could be used as well as giving the developer
a little motivation simply because there will be people waiting for them
to finish work by that set time.

As for bigger changes or anything unclear the mailinglist will be the
primary mean of discussing these issues. If you have any ideas what
could or should be changed/added/removed post away.

And last but not least everyone please try to commit your work to CVS as
soon as it doesn't break things anymore. I know there will be times
when this can't be done easily like my rewrite of the ViewPlatform needs
to be one bigger change as it breaks everything related to it, but most
times it's preferable to have the code available for everyone also if
it's not fully working yet.

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

The obscure we always see sooner or later;
the obvious always seems to take a little longer. (Edward R Murrow)

Re: [SrcML] a little bug

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

On Fri, Sep 02, 2005 at 04:29:32PM +0200, Icaro wrote:
> Hi
> first of all I want to tell you that I find SrcMl very interesting and I 
> hope that its development actively will continue in the future

As it looks like right now we still have at least 3 active developers.
Though they are not as active as they would be in a perfect world I
think it should be enough to get some more interesting things done :)

> Now, I wanted to signal you a small problem in the script  parse.py
> 
> in the line 51 should be changed by
> 
>        plugin = PluginManager.loadPlugin(pname, 
> PluginManager.TYPE_PARSER, None)
> to
> 
>        plugin = PluginManager.loadPlugin(pname, None, 
> PluginManager.TYPE_PARSER)

That's right. There used to be an inconsistency when we switched to the
new plugin manager. However I don't know which version of SrcML you are
using, as according to the CVS logs this bug has been dealt with back in
June. Please get the latest CVS version of the bin module for a more up
to date version.

PS: Starting with srcml-0.2.1 all platforms are accessible through Java
directly and the bin module is therefore considered deprecated. See the
Introduction page on the Wiki on srcml.de for a few examples. Quick
start: "java de.srcml.parser.Parser" should work similar to calling
"jython parse.py" (takes similar parameters, etc)

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

"There are 10 types of people in this world; those who understand
binary and those who don't."

Re: [SrcML] ViewPlatform improvements

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

On Thu, 25 Aug 2005 13:29:33 +0200
Frank Raiser <fra...@un...> wrote:

> 
> Now that the practical is basically over I liked to know who is still
> interested in working on SrcML and discussing such issues. I'm not
> writing these mails because I got nothing better to do, but to provoke
> constructive feedback. However if nobody's interested in that I could
> save the effort of trying to keep you updated on the current design
> questions and stop giving you the chance to influence the project.
Still here ;)
Currently I'm a bit busy (and not exactly with learning for exams...) -
but I'm still interested.

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

-
Dennis

[SrcML] a little bug

[Icaro <ic...@gm...>]

Hi
first of all I want to tell you that I find SrcMl very interesting and I 
hope that its development actively will continue in the future

Now, I wanted to signal you a small problem in the script  parse.py
 
in the line 51 should be changed by

        plugin = PluginManager.loadPlugin(pname, 
PluginManager.TYPE_PARSER, None)
to

        plugin = PluginManager.loadPlugin(pname, None, 
PluginManager.TYPE_PARSER)
 
Good job to everybody

-- 
Domenico (aka ^I^caro)

http://preponderante.splinder.com  <-- personale
http://icaro.blogspot.com          <-- perhaps technical
          
     ~~~~     "Dove mai andiamo?"......"Sempre a casa"....   ~~~~

[SrcML] ViewPlatform

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

Hi,

first of all, I announce that I'm still interested in the development  
of SrcML. But it has to be clear, that it is now only an activity in  
my spare time, so the response time may be a bit longer.

For the new ViewPlatform, I'm tending to a rewrite with a single  
method for each tag. It's much clearer how it works, so you can find  
easier access if you want to modify or create a new plugin. This will  
work similar to the XSLT solution, but with the advantage to also use  
methods and constants defined in the API. Also we don't lose the  
ViewPlatform itself and can provide a framework with an unique  
structure.

The idea of the event system needs more discssion, or in fairness  
more detailed thoughts from my side :)

 > Leif

P.S.: This answer is much shorter now, than promised, but I discussed  
this with Frank before.

[SrcML] ViewPlatform improvements

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

Attention: Long posting ahead. If you don't want to read it all at least
read the last paragraph please.

So here's another shot at how the current ViewPlatform could be
improved:

The distinction of our three main objectives is in principal very
powerful for creating new views which are derived from existing ones and
only change little aspects. However I don't think the additional
learning overhead to understand this system really justifies that.

What do you think of reducing the complexity by reducing view plugins to
a single class with a method for each tag? These methods will be
responsilbe for the ordering of the child nodes, the generated strings
and the generated whitespace.

A new plugin could still be derived from an existing and only some
methods could be overwritten. The downside of course is that for
changing only whitespace the whole method would have to be rewritten.
But as I mentioned above I think it's far easier to copy/paste that
method and modify the parts you want changed than understand the current
split into the various plugins, the indexing scheme and its
implications. Not even mentioning that we will not see too many derived
plugins anyways.

There's one more problem I can see with this approach. Interacting with
the generation mechanism would be more difficult. The current Iterator
would be gone, as each method is itself responsible for deciding which
nodes will be printed next and this will not be calculated in advance
(again this will be easier to understand I think). So hooking into this
process from some other code gets a bit trickier. Imagine the HTML view
which wants to use the normal view plugin and surround certain nodes'
output with the corresponding HTML tags.
An idea how to solve this would be denying the view plugin access to the
actual output plugin used, but providing it with an event system, so
that the plugin can send events. Those events will be caught by the
base Plugin class which forwards them appropriately to the output
plugin. On the other hand any other code fragment interested to interact
with the generation can register its own listeners.

Here's an example of how I'd imagine a view plugin to look like then
(minus the excess comments to stay realistic ;)

public void _handleNode(de.srcml.dom.Class f_class)
{
    // the handleNodes method would be a helper method defined in the
    // Plugin baseclass which takes a List of nodes for which events
    // will be generated that cause the baseclass to call the
    // corresponding methods of the plugin.
    // The f_class parameter is supplied, so that each event can be
    // marked with the node it was sent from.
    handleNodes(f_class, f_class.getCommentAndJavadocNodes());

    // same as above
    handleNodes(f_class.getAnnotationNodes());

    // same as the above, just for a single node
    handleNode(f_class.getModifiersNode());

    // here's an actual output. As mentioned above this will not be sent
    // to the output plugin directly, but results in an event (four
    // types of events possible as far as I can see: strings, inner whitespace
    // w/o linebreaks, linebreaks and indents)
    if (f_class.getModifiersNode() == null) outputWS(" ");
    outputString("class");
    outputWS(" ");
    outputString(f_class.getAttribute(de.srcml.dom.Class.ATTR_NAME));

    handleNode(f_class.getParameterizationNode());

    if (f_class.getBaseclassesNode() != null) {
        outputWS(" ");
        handleNode(f_class.getBaseclassesNode());
    }

    if (f_class.getInterfacesNode() != null) {
        outputWS(" ");
        handleNode(f_class.getInterfacesNode());
    }

    // a newline should get it's own event (should be simple to add line
    // numbers f.ex.)
    outputNewline(f_class);

    // Indents are different from simple spaces between identifiers, but
    // it's not absolutely neccessary to handle these separately
    //outputIndent(f_class);
    // (of course you don't really want to indent the class' block. but
    // a call like this would be due in the method handling
    // de.srcml.dom.Block f.ex.)

    handleNode(f_class.getBlockNode());
}

This code is of course very similar to the existing code, but unifies
the content of all 3 methods: getPermutation, getString and getBefore in
a way that everyone can far more easily imagine how the output will look
like.

A final point of consideration would be whether we want to allow
registered listeners to turn down an event. This means fixing the call
order to the inverse registration order and the called method returning
false meaning that the event will be thrown away. I can imagine this to
be useful f.ex. when wanting to print code without comments, or only to
a certain detail level (like no expressions) etc.






Now that the practical is basically over I liked to know who is still
interested in working on SrcML and discussing such issues. I'm not
writing these mails because I got nothing better to do, but to provoke
constructive feedback. However if nobody's interested in that I could
save the effort of trying to keep you updated on the current design
questions and stop giving you the chance to influence the project.

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

Should array indices start at 0 or 1?
My compromise of 0.5 was rejected without, I thought, proper consideration.
(Stan Kelly-Bootle)

[SrcML] ViewPlatform or XSLT

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

I've thought about how we could simplify the ViewPlatform and its
various plugins, as they are getting more and more complicated and
harder to maintain.
To keep things short: I've come back to the initial idea of using XSLT
stylesheets to do the conversion. This means that the
PrintSelectionPlugin (which currently has two responsibilities - node
ordering and string generation) and WhitespacePlugin would all be
merged together. In a stylesheet all 3 responsibilities will be handled
by each template. Here's the current list of pros and cons for XSLT
usage. If you know of any further reasons please add them to the list on
http://www.uni-ulm.de/~s_fraise/cgi-bin/moin.cgi/ToDo

* Pros for XSLT:
  o No need to learn details about the ViewPlatform, whereas many developers are already familiar with XSLT/XPath
  o Allows easy adjustment of output even for people not very familiar with the inner workings
  o Removes the distinction of print selection, printed strings and whitespace and ties it all into one small template
* Cons for XSLT:
  o Can be harder to write than java for complicated tasks
  o XSLT/XPath as additional languages must be known to the programmer
  o Subclassing plugins is not possible. Instead the whole stylesheet has to be copied and modified.

I'm currently working on a sample implementation and here's a small part
of how such a stylesheet would look like:

<xsl:template match="method">
  <xsl:apply-templates select="comment|javadoc"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:apply-templates select="modifiers"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:apply-templates select="type"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:if test="@type != 'constructor'"><xsl:text> </xsl:text></xsl:if>
  <xsl:value-of select="@name"/>
  <!-- TODO parameterization-->
  <xsl:text>(</xsl:text>
  <xsl:apply-templates select="parameters"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:text>)</xsl:text>
  <xsl:apply-templates select="throws"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:text>&#10;</xsl:text>
  <xsl:apply-templates select="block"><xsl:with-param name="indent" select="$indent"/></xsl:apply-templates>
  <xsl:text>&#10;</xsl:text>
</xsl:template>

<xsl:template match="modifiers">
  <xsl:call-template name="WS"><xsl:with-param name="indent" select="$indent"/></xsl:call-template>
  <xsl:for-each select="modifier">
    <xsl:value-of select="@name"/>
    <xsl:text> </xsl:text>
  </xsl:for-each>
</xsl:template>

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

parsing strings with commands designed to parse strings is the worlds 
leading killer of poorly written scripts. -- unknown

[SrcML] SrcML 0.2.1 released

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

= Changes for release 0.2.1 = 

== major changes == 

 * support for javadoc 
 * direct commandline support for `de.srcml.util.Transformation`, `de.srcml.util.Beautifier`, `de.srcml.view.View`, and `de.srcml.parser.Parser` 
 * configurable ant task for the analyzer platform 
 * added support for parsing only small structures (like expressions, methods or types) 

== minor changes == 
 
 * automatic conversion of plugin parameters when given as `java.lang.String` (requires constructor with `java.lang.String` argument) 
 * improved print selection and whitespace plugins for java 
 * several API cleanups 
 * several parser bugs fixed 

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

Fisher's Fundamental Theorem:
The more highly adapted an organism becomes,
the less adaptable it is to any new change. (R A Fisher)

[SrcML] ChangeLog and Javadocs

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

I have created a ChangeLog [1] page on the wiki to better document the
development process after the 0.2 release. If you make any changes to the
codebase please add a short entry to the ChangeLog list.
This serves as a remainder just as well as allowing others to stay informed
about the current changes. The list is split up into major and minor changes,
whereas the major changes should be those which will be mentioned in the next
release message.

I also added support for javadoc tags to the API. A few changes had to be made
to how javadoc comments are treated [2] and printed through the
PrintSelectionPlugin. The javadoc support does not care about the tags
actually defined by the javadoc specification. Any tag name could be used.
Therefore we also don't know if a tag is parameterized (like f.ex.
@param <param name> <description>) and we treat all tags equal as
@tag <description>. If you want to work with @param you would have to manually
cut off the first word from the description to get the actual parameter name.
I'm not sure if we should integrate support for that into the API, as we would
have to support tags with a multiple number of parameters too then.
In order to not destroy significant whitespace within comments the description
might contain actual \n characters to mark linebreaks.
Here's a sample javadoc comment and what the API is seeing:

/**
 **Some text
 * * split into two lines.
 * @param f_param parameter description
 * @return
 something is returned
 */

Javadoc.getComment() will return "Some text * split into two lines."
Javadoc.getTags() will return a List<Javadoc.Tag> with the first tag
being the param tag with tag.getName() returning "param" and 
tag.getDescription() returning "f_param parameter description". The
second tag will have the name "return" and the description will
reflect the newline: "\nsomething is returned".

When printed through the ViewPlatform again the comment should look like
this:

/**
 * Some text * split into two lines.
 *
 * @param f_param parameter description
 * @return
 * something is returned
 */


[1] http://www.uni-ulm.de/~s_fraise/cgi-bin/moin.cgi/ChangeLog

[2] I'm aware that it's impossible to interpret comments correctly, but I hope
that the current implementation destroys as few significant parts of the
comment as possible, while still creating a decent output.

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

Poor management can increase software costs more rapidly
than any other factor. (Barry Boehm)

[SrcML] new dependency for getopt

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

As I'm in the process of eliminating the jython scripts [1] I needed
a proper getopt implementation. I have now found an implementation which
guarantees 100% compatibility with the C version and is released under
the LGPL. It was added to the list of dependencies on the wiki and for
CVS development you need to download [2] the jar file and throw it to the
other files in your jars/ directory.

[1] I want to reduce the amount of release files, as one srcml.jar and
 the plugins.zip should be all a user needs to get started. However the
 jython scripts require an additional 3rd-party program and another
 downloadable module from us, so it's preferred to remove that dependency.
 This will also make it way easier to run SrcML on other platforms, as
 we only need to get that single srcml.jar into the $CLASSPATH and can
 then run:
  java de.srcml.parser.Parser MyClass.java
 And all we need for that is a JVM.

[2] http://fink.sourceforge.net/pdb/package.php/java-getopt

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

"Of course, just because we've heard a spine-chilling, blood-curdling
scream of the sort to make your very marrow freeze in your bones doesn't
automatically mean there's anything wrong."
        -- (Terry Pratchett, Soul Music)

[SrcML] SrcML 0.2 Released

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

The SrcML Framework allows converting Sourcecode to a XML representation on which several tools can then be used to deduce statical data for analyzing and/or visualizing the initial source. It also provides easy ways to write programs which modify other programs. 
 
Today we proudly present the 0.2 release of SrcML containing the following changes from 0.1: 
  
  - major restructuring into a single main module 
  - various API improvements 
  - far improved plugin system 
  - addition of AnalyzerPlatform 
  - Beautifier and Transform utilities 
  - parser and view updates to java 5 

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

I have not failed. I've just found 10,000 ways that won't work. (Thomas Edison)

[SrcML] preparations for 0.2 release

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

For those of you who don't know it yet: I'm planning to release the
0.2 version of SrcML in the beginning of next week.

Here are the most important changes from 0.1:

- major restructuring into a single main module
- far improved plugin system
- various API improvements
- addition of AnalyzerPlatform
- parser and view updates to java 5
- Beautifier utility

I'm planning to also add a Transform utility which is able to 
transparently run XSLT stylesheets on source code.
(i.e. source -> SrcML -> XSLT -> SrcML' -> source')
The basic functionality for this has all been implemented by now and I
already used the XSLT approach very successfully today when removing the
checkDTD() methods from the API classes.

If anyone wants some of his or her work to be included in the 0.2
release please let me know in time.
You can check the current state of what's missing for the release on:
http://www.uni-ulm.de/~s_fraise/cgi-bin/moin.cgi/ToDo

PS: The ToDO list is open for everyone working on the project, so you can
add your own entries too. It's especially useful to write tasks down you
don't want to get done right away so you don't forget them and can return
to them later. (And if you decide the task shouldn't really be done you
can of course remove it again just as easily)

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

Without deviation, progress is not possible. (Frank Zappa}

[SrcML] ant convert + webpage

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

As I have not gotten any complaints about the new wiki we have now replaced
the link for http://srcml.de to point to the new moin moin wiki.

Now for something totally different..
I have written the class de.srcml.util.Beautifier which runs a java file
through the parser and view platforms (just like beautify.py) and writes
the result back into the original file.
As we have already discussed we should use the ViewPlatform for the contents
of our CVS repository for several reasons including:

 * we are forced to fix bugs ASAP as we couldn't commit anything otherwise
 * we have to work with sourcecode created by the ViewPlatform which means
   additional effort will go into improving the print selection and whitespace
   plugins
 * we get rid of annoying CVS diffs because of simple whitespace modifications
 * we cannot tell anyone to use SrcML when we're not using it ourselves

--------------------------------------------------
ATTENTION everyone with CVS write access:
Before commiting your changes to CVS run 'ant convert' to run the files
through the Beautifier. Do not commit files which you modified with any
normal editor and did not run through the Beautifier!
--------------------------------------------------

(You can speed up the process a little bit by manually running the Beautifier
only on your modified file or directory)


PS: Of course using our beta software here is a risk. If you make any large-scale
changes you better create a backup copy before running the Beautifier on those
files just to make sure. (Again check the reasons list above for why we use the
Beautifier nevertheless)

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

A common mistake that people make when trying to design something completely
foolproof was to underestimate the ingenuity of complete fools.
(Douglas Adams)

[SrcML] new SrcML webpage

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

As you all know our current webpage isn't really enjoyable to use due
to the very high load times. I have now tried to setup a MoinMoin wiki
on my KIZ account which seems to work splendidly. It's faster to open
4 pages on this wiki and start editing the page than loading a single
page on the old media wiki.

Therefore I suggest we switch to using the MoinMoin wiki instead. I have
already migrated most parts of the old content to the new wiki (and updated
some of it at the same time) and urge everyone to take a look at it:

http://www.uni-ulm.de/~s_fraise/cgi-bin/moin.cgi

It doesn't look as good as media wiki by default, but with the new 1.3
release it doesn't look like crap anymore either :)

Help on how the wiki works and what to know about editing is provided on
the wiki itself (just click on HelpContents in the navigation bar) and as
wikis are supposed to be easy it doesn't take more than a few minutes in
order to be able to modify a page or create new ones.

If there are no complaints I suggest we fully switch to the new wiki and
adjust srcml.de and the link from the SourceForge project page accordingly.

@Leif: Feel free to add some content to the AnalyzerPlatform page
@Dennis: the API page doesn't contain information about the new configs yet
@Claudia: if you already want to you can add information about SrcML2UML too

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

Not all comments are bad. But they are generally deodorant;
they cover up mistakes in the code. (Christian Sepulveda)

[SrcML] SrcML2UML

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

Hi everybody,

as you know I'm going to implement a program presenting SrcML-Code in a UML2.0 ClassDiagramm. The program will be called as mentioned above 
if you don't mind. SrcML2UML will save the created data in a format which can be opend by MS Visio 2003. The XML  interface of Visio is described in the following link:

http://www.microsoft.com/downloads/details.aspx?FamilyId=FE118952-3547-420A-A412-00A2662442D9&displaylang=en

Visio 2003 uses  an XML Schema called DataDiagramingML which is discrebed in the link above.

Of course the data can only be read under Windows ;-)

Greets
Claudia

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

[SrcML] Plugins and new Configuration

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

Hi there

The current cvs version has some important changes in plugins and 
configuration thereof:
You must not instantiate Plugins yourself. Always call the setXXXPlugin 
methods on the various platforms.
If you happen to create one, it will crash immediatly after you try to 
use the platform.

Configuration:
Parameters of plugins are now saved in their "plugin.xml" within the 
following structure:
<config>
    (<configelement name="NameOfTheParameter" type="TypeOfTheParameter"/>)*
</config>

where (...)* means "as many as you like". The type attribute must be a 
valid java Object.
Note: These config settings are checked runtime and will throw Errors if 
something is going wrong.

If you're writing your own plugin, you may not overwrite the 
"setParameter" method as was done before. Instead you need to register a 
ParameterChangeListener with your own plugin to receive parameter 
changes. Check an already implemented plugin like InputFile for an example.

Good day - and if I forgot something/made an error - feel free to comment.

-
Dennis

[SrcML] Java 1.5

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

The new java 1.5 parser is now in CVS. All the new tag classes
have been added as well and the ViewPlatform was adjusted too. Right
now the unittests work, but as mentioned earlier we still need to
find a project which actually uses java 1.5. The current 1.3 projects
however parse fine.

There seems to be a problem though when you have the old CVS modules
still lieing around. To avoid this problem I will soon do a support
request on SourceForge to have those modules removed. If you get a
strange ClassCastException make sure you only have the srcml, 
parser-java, views and unittests modules checked out.

Also some unittests don't work yet, as the Schema was changed and some
of these changes still have to be taken care of in the API. I don't
consider the new 1.5 parser stable yet, but at least the unittests for
schema and view work. (You can run them with 'ant view' and 'ant schema')
Please let me know if you run into any troubles with the new parser and
feel free to try to parse some selected 1.5 example sources with it.

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

Osborn's Law:
Variables won't; constants aren't. (Don Osborn)

Re: [SrcML] PluginConfig

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

On Wed, Jun 01, 2005 at 06:45:44PM +0200, Leif Bladt wrote:
> The getPluginList-method in the PluginManager gives back an ArrayList 
> with PluginConfig objects. Shouldn't be the PluginConfig class declared 
> public to access it outside? Or should the getPluginList method get 
> another return value?

You're right. Of course you are supposed to work with the PluginConfig
objects (especially as they will be the only means to access platform
specific configuration data). I don't know why the class wasn't declared
public, but it was never intended that way. I've already changed the CVS
and made it public. 
Thanks for the hint and enjoy working with public data now :)

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

There is no method but to be very intelligent. (T S Eliot)

[SrcML] PluginConfig

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

The getPluginList-method in the PluginManager gives back an ArrayList 
with PluginConfig objects. Shouldn't be the PluginConfig class declared 
public to access it outside? Or should the getPluginList method get 
another return value?

 > Leif