Re: [SrcML] problems in plugin building

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

On Fri, Nov 25, 2005 at 04:39:08PM +0100, Icaro wrote:
> Hi 

Hello,

> I am trying to create a ViewPlugin but I have found some problems. 

Any specific idea on what the plugin is supposed to do or are you just
toying around with the ViewPlugins? In the first case let us know and
maybe we can include it in the official SrcML distribution.

> I have created a new project (using Eclipse) inserting srcml-0.2.2.jar 
> in the classpath  and
> then I have copied the sources of ViewXHTML.java to have a starting point. 

Oops. That's not going to work. The ViewXHTML.java currently in CVS is
still building upon the old ViewPlatform. Leif is right now working on
porting it over to the new platform.

> However there are some problems because the following names cannot be 
> resolved 
> m_outupt, SelectionPair, output, m_line and m_column 

Right. The whole SelectionPair process was rather complicated and tough
to get into. The new ViewPlatform is a lot easier in that respect. The
problem right now is that we just recently switched to this new platform
and so we still have some of the older stuff left in CVS (mainly because
we didn't know if the new concept was going to work out and wanted to be
able to do a rollback on the old platform). I'll have to publish a
SourceForge support request for the removal of those outdated
directories soon.
For now I suggest you take a look at the current ViewJava plugin:
http://cvs.sourceforge.net/viewcvs.py/srcml/views/ViewJava/de/srcml/view/java/ViewJava.java?view=markup

I'm sorry that the documentation on the wiki is deprecated in that area,
but I have to get into contact with Simon first, as I'm not sure if his
last report contained the documentation for the new ViewPlatform too and
it would be quite a waste of time to unneccessarily rewrite it. But for
now I'll quickly mark the documentation on the wiki as deprecated.
Thanks for pointing this out.

> PS: is it possible to have in the output of SrcML the line in which a 
> statement was present in the original source file? (e.g. <class name = 
> "StatementTest" row=28>  )

Short answer: officially not

Detailed answer: As SrcML is abstracting from the actual line-by-line
representation of source code there is nothing like a positional
information in terms of 'lines' contained in a SrcML document. In our
vision even something like the 'original source file' is not really
applicable, as you would save your sources directly in SrcML which
pretty much replaces the meaning of what the 'original source file' is.

Hackish answer: Despite the above there is of course the technical
possibilty to get what you want. If you modify the existing parser to
include the positioning of tokens in the resulting SrcML document you
(currently [1]) break the Schema, but apart from that you get the
information you wanted. If you want to go that way I can direct you
towards the java.tree.g file in the parser-java module. It shouldn't be
too difficult to add this information as ANTLR tokens always know their
original location in the source code. It's just a lot of effort to add
this information everywhere, because the grammar file is several
thousand lines long.

> PPS: is it still working the possibility to have an XML output with a 
> specified level of detail? (I believe it was the option - g...I'have 
> read something in the SrcML documentation)

No. This was an idea we incorporated from similar projects some years
ago [2]. However I'd like to know what use you have for such a feature. The
only advantage I can come up with is that the parsing process would be
faster (of course it would still be linear in the file size). But if you
can live with a full SrcML document you get all levels of details for
free, as you can simply choose how deep you walk down the DOM tree.

[1] Breaking the SrcML schema is rather unimportant at this point. I've
come to the conclusion, that the current schema is our major drawback
and I'm trying to shift my diploma thesis such that I can work on
creating a proper schema. The current schema is very java centric and
should work fine as long as you don't mix in new languages, but even
then it's unneccessarily complicated at a lot of places due to the
inherent similarity to the parser's abstract syntax tree. Also right now
the schema is very stringent in that it does not allow you to extend
SrcML documents which I also consider a major drawback (say you want to
include some MathML or SVG or your design diagrams in the form of XMI -
currently not allowed by the schema)

[2] Have you found the information about detail levels in the parser on
any of the current wiki pages? If yes could you please tell us which
one, so it can be updated accordingly.

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

"Only wimps use tape backup: _real_ men just upload their important stuff on
 ftp, and let the rest of the world mirror it ;)"  -- Linus Torvalds