Re: [SrcML] Attention: Future of SrcML project

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

Frank Raiser ha scritto:

>On 12/13/05, Domenico <ic...@in...> wrote:
>  
>
>>>The major part of my thesis will be the proper definition of the SrcML
>>>XSL schema. The new schema will not be inherently related to the Java
>>>AST anymore, but I'll take at least Java, C# and C++ into account.
>>>
>>>      
>>>
>>What about a scripting language?
>>For classical language, I think you could support also 'D'
>>    
>>
>
>As I said the schema will be extensible. You can think of the one I'm
>developing as a 1.0 version, so if you want to add D and/or a
>scripting language you could make that version 1.1 with full downward
>compatibility. As I only have a limited amount of time available I
>will not be able to prepare the schema for 500 languages. 
>

Of course! :-)

>>>- Does it make sense to continue our own parser(s)?
>>>      
>>>
>>Yes, for me. I think that it is a good model. To be semplified but not
>>to throw away entirely.
>>    
>>
>
>I'm not talking about the model, but about the parser. My main concern
>is that with the excessive amount of maintainance we might end up with
>a dead project. I don't know how much time I can and want to devote to
>the maintainance of a parser which is obviously deferior compared to
>the existing other choices.
>  
>

there will be at least a 0.2.3 (0.3?) release with the changes and the 
bugs fix of the last months?

>>>- What good is the API if we move to Eclipse (which already comes with
>>>a huge API itself)?
>>>      
>>>
>>Not all the peaples want to use Eclipse. Not all will use SrcML with Eclipse
>>
>>You want to realize a plugin for Eclipse as Jezix?
>>    
>>
>
>For the purpose of my thesis the plugin will be similar to Jezix, but
>it will probably be quite rough in terms of usage (due to
>implementations generally not adding much value to a thesis ;)
>  
>
hmpf...not for my teacher? :-(

>However there is the mid-term option of moving the code into a rich
>client building upon eclipse. This means you will again end up with a
>.jar file which can be used similarly to the currently existing
>version. Due to the plugin nature of Eclipse we can at any time
>extract the necessary plugins and maybe add some glue code for a
>commandline interface or whatever is needed. I don't see too much of a
>problem there. 
>
this would be excellent for me :-)
further to be a good library, I appreciate your tool because it is 
easily usable from the command line


>>>- How can we increase the popularity of SrcML at this point (in order
>>>to get more developers and testers on board)?
>>>      
>>>
>>with some publications, but if it works it will automatically increase
>>it's popularity ;-)
>>    
>>
>
>I actually doubt that. There are a lot of small
>applications/libraries/XML formats around like SrcML. And at least at
>this moment we are not really better than those. 
>

The true difference that I have found (that has made me choose SrcML) is 
the presence of an API that allowed me to reprocess the outputed xml.
the View platform is a point for you.
What about the UML representation that you were working on?


>>>- Can we find (and implement) any killer applications showing off the
>>>advantages of SrcML?
>>>      
>>>
>>I'm doing it! ;-)
>>    
>>
>
>Good. I will try to get one started for my thesis too, but I have no
>idea how long it'll take until it's in a useable state beyond the
>selected usage examples. It'll definitely not attract new users or
>developers anytime soon.
>

For the chronicle, as I have told on this mailing list, I am creating a 
system for a fine grained configuration management system that uses 
SrcML to get the structure (xml) of a source file (java), and to create 
a new file representation that contains additional information such as 
author, date etc. etc.

Domenico

Ps: I'm sorry to not having free time in this period. I hope to be able 
to give an hand in the future
-- 
http://icaro.blogspot.com