srcML for C++ and Java

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

srcML for C++ and Java

jannik laval
Hi all,

I am looking at srcML, and I see that it make XML files from Java and C++ source code.

Since we use it for C source code, it should be possible to make it works with C++ and java.
This strategy allows us to not us a special tool for each language.

What do you think about it ?

Cheers
---
Jannik Laval


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Stéphane Ducasse
the problem is that meta model is different so you would have to map everything.

Stef


On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:

> Hi all,
>
> I am looking at srcML, and I see that it make XML files from Java and C++ source code.
>
> Since we use it for C source code, it should be possible to make it works with C++ and java.
> This strategy allows us to not us a special tool for each language.
>
> What do you think about it ?
>
> Cheers
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Simon Denier-3

On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:

> the problem is that meta model is different so you would have to map everything.


Besides, from what I have seen, the generated xml is sometimes not regular: i.e. similar things in the code does not have the same xml representation. This makes it cumbersome as it is not documented, so you have to decode the grammar from the xml and adapt to such irregularities.

In the end, you still have to maintain a xml parser for each language and you still dont have control about what is extracted. And you have to do the type resolution :)


>
> Stef
>
>
> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>
>> Hi all,
>>
>> I am looking at srcML, and I see that it make XML files from Java and C++ source code.
>>
>> Since we use it for C source code, it should be possible to make it works with C++ and java.
>> This strategy allows us to not us a special tool for each language.
>>
>> What do you think about it ?
>>
>> Cheers
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
As Simon said, the type resolution in C is easy. In C++ it is another  
beast.

Alexandre


On 28 Apr 2010, at 04:47, Simon Denier wrote:

>
> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>
>> the problem is that meta model is different so you would have to  
>> map everything.
>
>
> Besides, from what I have seen, the generated xml is sometimes not  
> regular: i.e. similar things in the code does not have the same xml  
> representation. This makes it cumbersome as it is not documented, so  
> you have to decode the grammar from the xml and adapt to such  
> irregularities.
>
> In the end, you still have to maintain a xml parser for each  
> language and you still dont have control about what is extracted.  
> And you have to do the type resolution :)
>
>
>>
>> Stef
>>
>>
>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>
>>> Hi all,
>>>
>>> I am looking at srcML, and I see that it make XML files from Java  
>>> and C++ source code.
>>>
>>> Since we use it for C source code, it should be possible to make  
>>> it works with C++ and java.
>>> This strategy allows us to not us a special tool for each language.
>>>
>>> What do you think about it ?
>>>
>>> Cheers
>>> ---
>>> Jannik Laval
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
Hi,

Another related idea is to not use srcML for the main parsing, but to  
keep it around for custom queries.

So, we could still keep the current solution with inFusion for the  
main models, and have srcML for when we want to write queries that  
need access to AST.

For example, if you do not have the right libraries, inFusion will not  
create annotation objects. If I would have access to the AST, I could  
write a query (even if it is expensive at first) that checks the AST  
of class for the existence of such annotations.

I would use this. And maybe like this the srcML interface would grow  
in time and get better. What do you think?

Cheers,
Doru



On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:

> As Simon said, the type resolution in C is easy. In C++ it is  
> another beast.
>
> Alexandre
>
>
> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>
>>
>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>
>>> the problem is that meta model is different so you would have to  
>>> map everything.
>>
>>
>> Besides, from what I have seen, the generated xml is sometimes not  
>> regular: i.e. similar things in the code does not have the same xml  
>> representation. This makes it cumbersome as it is not documented,  
>> so you have to decode the grammar from the xml and adapt to such  
>> irregularities.
>>
>> In the end, you still have to maintain a xml parser for each  
>> language and you still dont have control about what is extracted.  
>> And you have to do the type resolution :)
>>
>>
>>>
>>> Stef
>>>
>>>
>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am looking at srcML, and I see that it make XML files from Java  
>>>> and C++ source code.
>>>>
>>>> Since we use it for C source code, it should be possible to make  
>>>> it works with C++ and java.
>>>> This strategy allows us to not us a special tool for each language.
>>>>
>>>> What do you think about it ?
>>>>
>>>> Cheers
>>>> ---
>>>> Jannik Laval
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"What we can governs what we wish."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
A model originally created with inFusion, could then be refined by  
loading srcML files, to add for example AST info.

Alexandre


On 29 Apr 2010, at 09:53, Tudor Girba wrote:

> Hi,
>
> Another related idea is to not use srcML for the main parsing, but  
> to keep it around for custom queries.
>
> So, we could still keep the current solution with inFusion for the  
> main models, and have srcML for when we want to write queries that  
> need access to AST.
>
> For example, if you do not have the right libraries, inFusion will  
> not create annotation objects. If I would have access to the AST, I  
> could write a query (even if it is expensive at first) that checks  
> the AST of class for the existence of such annotations.
>
> I would use this. And maybe like this the srcML interface would grow  
> in time and get better. What do you think?
>
> Cheers,
> Doru
>
>
>
> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>
>> As Simon said, the type resolution in C is easy. In C++ it is  
>> another beast.
>>
>> Alexandre
>>
>>
>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>
>>>
>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>
>>>> the problem is that meta model is different so you would have to  
>>>> map everything.
>>>
>>>
>>> Besides, from what I have seen, the generated xml is sometimes not  
>>> regular: i.e. similar things in the code does not have the same  
>>> xml representation. This makes it cumbersome as it is not  
>>> documented, so you have to decode the grammar from the xml and  
>>> adapt to such irregularities.
>>>
>>> In the end, you still have to maintain a xml parser for each  
>>> language and you still dont have control about what is extracted.  
>>> And you have to do the type resolution :)
>>>
>>>
>>>>
>>>> Stef
>>>>
>>>>
>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am looking at srcML, and I see that it make XML files from  
>>>>> Java and C++ source code.
>>>>>
>>>>> Since we use it for C source code, it should be possible to make  
>>>>> it works with C++ and java.
>>>>> This strategy allows us to not us a special tool for each  
>>>>> language.
>>>>>
>>>>> What do you think about it ?
>>>>>
>>>>> Cheers
>>>>> ---
>>>>> Jannik Laval
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "What we can governs what we wish."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
Exactly.

Doru

On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:

> A model originally created with inFusion, could then be refined by  
> loading srcML files, to add for example AST info.
>
> Alexandre
>
>
> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>
>> Hi,
>>
>> Another related idea is to not use srcML for the main parsing, but  
>> to keep it around for custom queries.
>>
>> So, we could still keep the current solution with inFusion for the  
>> main models, and have srcML for when we want to write queries that  
>> need access to AST.
>>
>> For example, if you do not have the right libraries, inFusion will  
>> not create annotation objects. If I would have access to the AST, I  
>> could write a query (even if it is expensive at first) that checks  
>> the AST of class for the existence of such annotations.
>>
>> I would use this. And maybe like this the srcML interface would  
>> grow in time and get better. What do you think?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>
>>> As Simon said, the type resolution in C is easy. In C++ it is  
>>> another beast.
>>>
>>> Alexandre
>>>
>>>
>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>
>>>>
>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>
>>>>> the problem is that meta model is different so you would have to  
>>>>> map everything.
>>>>
>>>>
>>>> Besides, from what I have seen, the generated xml is sometimes  
>>>> not regular: i.e. similar things in the code does not have the  
>>>> same xml representation. This makes it cumbersome as it is not  
>>>> documented, so you have to decode the grammar from the xml and  
>>>> adapt to such irregularities.
>>>>
>>>> In the end, you still have to maintain a xml parser for each  
>>>> language and you still dont have control about what is extracted.  
>>>> And you have to do the type resolution :)
>>>>
>>>>
>>>>>
>>>>> Stef
>>>>>
>>>>>
>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am looking at srcML, and I see that it make XML files from  
>>>>>> Java and C++ source code.
>>>>>>
>>>>>> Since we use it for C source code, it should be possible to  
>>>>>> make it works with C++ and java.
>>>>>> This strategy allows us to not us a special tool for each  
>>>>>> language.
>>>>>>
>>>>>> What do you think about it ?
>>>>>>
>>>>>> Cheers
>>>>>> ---
>>>>>> Jannik Laval
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "What we can governs what we wish."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"We are all great at making mistakes."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Stéphane Ducasse
well probably now with how much effort.

stef

On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:

> Exactly.
>
> Doru
>
> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>
>> A model originally created with inFusion, could then be refined by loading srcML files, to add for example AST info.
>>
>> Alexandre
>>
>>
>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> Another related idea is to not use srcML for the main parsing, but to keep it around for custom queries.
>>>
>>> So, we could still keep the current solution with inFusion for the main models, and have srcML for when we want to write queries that need access to AST.
>>>
>>> For example, if you do not have the right libraries, inFusion will not create annotation objects. If I would have access to the AST, I could write a query (even if it is expensive at first) that checks the AST of class for the existence of such annotations.
>>>
>>> I would use this. And maybe like this the srcML interface would grow in time and get better. What do you think?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>
>>>> As Simon said, the type resolution in C is easy. In C++ it is another beast.
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>
>>>>>
>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>
>>>>>> the problem is that meta model is different so you would have to map everything.
>>>>>
>>>>>
>>>>> Besides, from what I have seen, the generated xml is sometimes not regular: i.e. similar things in the code does not have the same xml representation. This makes it cumbersome as it is not documented, so you have to decode the grammar from the xml and adapt to such irregularities.
>>>>>
>>>>> In the end, you still have to maintain a xml parser for each language and you still dont have control about what is extracted. And you have to do the type resolution :)
>>>>>
>>>>>
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am looking at srcML, and I see that it make XML files from Java and C++ source code.
>>>>>>>
>>>>>>> Since we use it for C source code, it should be possible to make it works with C++ and java.
>>>>>>> This strategy allows us to not us a special tool for each language.
>>>>>>>
>>>>>>> What do you think about it ?
>>>>>>>
>>>>>>> Cheers
>>>>>>> ---
>>>>>>> Jannik Laval
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "What we can governs what we wish."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "We are all great at making mistakes."
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
It is cost that I had in mind from the beginning. Now, we have  
CAnalyzer in place, so I guess it would be quite cheap to generalize  
it a bit and to hook it with the FAMIXFileAnchor to get an AST of it.

Cheers,
Doru


On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:

> well probably now with how much effort.
>
> stef
>
> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>
>> Exactly.
>>
>> Doru
>>
>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>
>>> A model originally created with inFusion, could then be refined by  
>>> loading srcML files, to add for example AST info.
>>>
>>> Alexandre
>>>
>>>
>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>
>>>> Hi,
>>>>
>>>> Another related idea is to not use srcML for the main parsing,  
>>>> but to keep it around for custom queries.
>>>>
>>>> So, we could still keep the current solution with inFusion for  
>>>> the main models, and have srcML for when we want to write queries  
>>>> that need access to AST.
>>>>
>>>> For example, if you do not have the right libraries, inFusion  
>>>> will not create annotation objects. If I would have access to the  
>>>> AST, I could write a query (even if it is expensive at first)  
>>>> that checks the AST of class for the existence of such annotations.
>>>>
>>>> I would use this. And maybe like this the srcML interface would  
>>>> grow in time and get better. What do you think?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>
>>>>> As Simon said, the type resolution in C is easy. In C++ it is  
>>>>> another beast.
>>>>>
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>
>>>>>>
>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>
>>>>>>> the problem is that meta model is different so you would have  
>>>>>>> to map everything.
>>>>>>
>>>>>>
>>>>>> Besides, from what I have seen, the generated xml is sometimes  
>>>>>> not regular: i.e. similar things in the code does not have the  
>>>>>> same xml representation. This makes it cumbersome as it is not  
>>>>>> documented, so you have to decode the grammar from the xml and  
>>>>>> adapt to such irregularities.
>>>>>>
>>>>>> In the end, you still have to maintain a xml parser for each  
>>>>>> language and you still dont have control about what is  
>>>>>> extracted. And you have to do the type resolution :)
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Stef
>>>>>>>
>>>>>>>
>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I am looking at srcML, and I see that it make XML files from  
>>>>>>>> Java and C++ source code.
>>>>>>>>
>>>>>>>> Since we use it for C source code, it should be possible to  
>>>>>>>> make it works with C++ and java.
>>>>>>>> This strategy allows us to not us a special tool for each  
>>>>>>>> language.
>>>>>>>>
>>>>>>>> What do you think about it ?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> ---
>>>>>>>> Jannik Laval
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "What we can governs what we wish."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "We are all great at making mistakes."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Yesterday is a fact.
  Tomorrow is a possibility.
  Today is a challenge."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
How the elements composing the AST can be represented. Maybe xml  
queries are enough at that level...

Alexandre


On 30 Apr 2010, at 09:02, Tudor Girba wrote:

> It is cost that I had in mind from the beginning. Now, we have  
> CAnalyzer in place, so I guess it would be quite cheap to generalize  
> it a bit and to hook it with the FAMIXFileAnchor to get an AST of it.
>
> Cheers,
> Doru
>
>
> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>
>> well probably now with how much effort.
>>
>> stef
>>
>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>
>>> Exactly.
>>>
>>> Doru
>>>
>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>
>>>> A model originally created with inFusion, could then be refined  
>>>> by loading srcML files, to add for example AST info.
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Another related idea is to not use srcML for the main parsing,  
>>>>> but to keep it around for custom queries.
>>>>>
>>>>> So, we could still keep the current solution with inFusion for  
>>>>> the main models, and have srcML for when we want to write  
>>>>> queries that need access to AST.
>>>>>
>>>>> For example, if you do not have the right libraries, inFusion  
>>>>> will not create annotation objects. If I would have access to  
>>>>> the AST, I could write a query (even if it is expensive at  
>>>>> first) that checks the AST of class for the existence of such  
>>>>> annotations.
>>>>>
>>>>> I would use this. And maybe like this the srcML interface would  
>>>>> grow in time and get better. What do you think?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>>
>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>
>>>>>> As Simon said, the type resolution in C is easy. In C++ it is  
>>>>>> another beast.
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>
>>>>>>>
>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>
>>>>>>>> the problem is that meta model is different so you would have  
>>>>>>>> to map everything.
>>>>>>>
>>>>>>>
>>>>>>> Besides, from what I have seen, the generated xml is sometimes  
>>>>>>> not regular: i.e. similar things in the code does not have the  
>>>>>>> same xml representation. This makes it cumbersome as it is not  
>>>>>>> documented, so you have to decode the grammar from the xml and  
>>>>>>> adapt to such irregularities.
>>>>>>>
>>>>>>> In the end, you still have to maintain a xml parser for each  
>>>>>>> language and you still dont have control about what is  
>>>>>>> extracted. And you have to do the type resolution :)
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Stef
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am looking at srcML, and I see that it make XML files from  
>>>>>>>>> Java and C++ source code.
>>>>>>>>>
>>>>>>>>> Since we use it for C source code, it should be possible to  
>>>>>>>>> make it works with C++ and java.
>>>>>>>>> This strategy allows us to not us a special tool for each  
>>>>>>>>> language.
>>>>>>>>>
>>>>>>>>> What do you think about it ?
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> ---
>>>>>>>>> Jannik Laval
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "What we can governs what we wish."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "We are all great at making mistakes."
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Yesterday is a fact.
> Tomorrow is a possibility.
> Today is a challenge."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
Hi,

As a first step I would just work with XML indeed. As a second step,  
if someone would start using it, it would probably start to make sense  
building the AST in the image and work with that.

Perhaps having a look at Opax would ease a bit in getting from XML to  
objects in the image.

Cheers,
Doru


On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:

> How the elements composing the AST can be represented. Maybe xml  
> queries are enough at that level...
>
> Alexandre
>
>
> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>
>> It is cost that I had in mind from the beginning. Now, we have  
>> CAnalyzer in place, so I guess it would be quite cheap to  
>> generalize it a bit and to hook it with the FAMIXFileAnchor to get  
>> an AST of it.
>>
>> Cheers,
>> Doru
>>
>>
>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>
>>> well probably now with how much effort.
>>>
>>> stef
>>>
>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>
>>>> Exactly.
>>>>
>>>> Doru
>>>>
>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>
>>>>> A model originally created with inFusion, could then be refined  
>>>>> by loading srcML files, to add for example AST info.
>>>>>
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Another related idea is to not use srcML for the main parsing,  
>>>>>> but to keep it around for custom queries.
>>>>>>
>>>>>> So, we could still keep the current solution with inFusion for  
>>>>>> the main models, and have srcML for when we want to write  
>>>>>> queries that need access to AST.
>>>>>>
>>>>>> For example, if you do not have the right libraries, inFusion  
>>>>>> will not create annotation objects. If I would have access to  
>>>>>> the AST, I could write a query (even if it is expensive at  
>>>>>> first) that checks the AST of class for the existence of such  
>>>>>> annotations.
>>>>>>
>>>>>> I would use this. And maybe like this the srcML interface would  
>>>>>> grow in time and get better. What do you think?
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>
>>>>>>> As Simon said, the type resolution in C is easy. In C++ it is  
>>>>>>> another beast.
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>
>>>>>>>>> the problem is that meta model is different so you would  
>>>>>>>>> have to map everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>> sometimes not regular: i.e. similar things in the code does  
>>>>>>>> not have the same xml representation. This makes it  
>>>>>>>> cumbersome as it is not documented, so you have to decode the  
>>>>>>>> grammar from the xml and adapt to such irregularities.
>>>>>>>>
>>>>>>>> In the end, you still have to maintain a xml parser for each  
>>>>>>>> language and you still dont have control about what is  
>>>>>>>> extracted. And you have to do the type resolution :)
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Stef
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am looking at srcML, and I see that it make XML files  
>>>>>>>>>> from Java and C++ source code.
>>>>>>>>>>
>>>>>>>>>> Since we use it for C source code, it should be possible to  
>>>>>>>>>> make it works with C++ and java.
>>>>>>>>>> This strategy allows us to not us a special tool for each  
>>>>>>>>>> language.
>>>>>>>>>>
>>>>>>>>>> What do you think about it ?
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> ---
>>>>>>>>>> Jannik Laval
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>> --
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "What we can governs what we wish."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "We are all great at making mistakes."
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Yesterday is a fact.
>> Tomorrow is a possibility.
>> Today is a challenge."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Problem solving should be concentrated on describing
the problem in a way that is relevant for the solution."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
> Perhaps having a look at Opax would ease a bit in getting from XML  
> to objects in the image.

I haven't checked the Store@SCG, but what is opax? It is not listed in  
the tools section of the moose website. ScgBib does not know about  
this word it apparently.

Cheers,
Alexandre

>
>
> On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:
>
>> How the elements composing the AST can be represented. Maybe xml  
>> queries are enough at that level...
>>
>> Alexandre
>>
>>
>> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>>
>>> It is cost that I had in mind from the beginning. Now, we have  
>>> CAnalyzer in place, so I guess it would be quite cheap to  
>>> generalize it a bit and to hook it with the FAMIXFileAnchor to get  
>>> an AST of it.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>>
>>>> well probably now with how much effort.
>>>>
>>>> stef
>>>>
>>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>>
>>>>> Exactly.
>>>>>
>>>>> Doru
>>>>>
>>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>>
>>>>>> A model originally created with inFusion, could then be refined  
>>>>>> by loading srcML files, to add for example AST info.
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Another related idea is to not use srcML for the main parsing,  
>>>>>>> but to keep it around for custom queries.
>>>>>>>
>>>>>>> So, we could still keep the current solution with inFusion for  
>>>>>>> the main models, and have srcML for when we want to write  
>>>>>>> queries that need access to AST.
>>>>>>>
>>>>>>> For example, if you do not have the right libraries, inFusion  
>>>>>>> will not create annotation objects. If I would have access to  
>>>>>>> the AST, I could write a query (even if it is expensive at  
>>>>>>> first) that checks the AST of class for the existence of such  
>>>>>>> annotations.
>>>>>>>
>>>>>>> I would use this. And maybe like this the srcML interface  
>>>>>>> would grow in time and get better. What do you think?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>>
>>>>>>>> As Simon said, the type resolution in C is easy. In C++ it is  
>>>>>>>> another beast.
>>>>>>>>
>>>>>>>> Alexandre
>>>>>>>>
>>>>>>>>
>>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>>
>>>>>>>>>> the problem is that meta model is different so you would  
>>>>>>>>>> have to map everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>>> sometimes not regular: i.e. similar things in the code does  
>>>>>>>>> not have the same xml representation. This makes it  
>>>>>>>>> cumbersome as it is not documented, so you have to decode  
>>>>>>>>> the grammar from the xml and adapt to such irregularities.
>>>>>>>>>
>>>>>>>>> In the end, you still have to maintain a xml parser for each  
>>>>>>>>> language and you still dont have control about what is  
>>>>>>>>> extracted. And you have to do the type resolution :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Stef
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I am looking at srcML, and I see that it make XML files  
>>>>>>>>>>> from Java and C++ source code.
>>>>>>>>>>>
>>>>>>>>>>> Since we use it for C source code, it should be possible  
>>>>>>>>>>> to make it works with C++ and java.
>>>>>>>>>>> This strategy allows us to not us a special tool for each  
>>>>>>>>>>> language.
>>>>>>>>>>>
>>>>>>>>>>> What do you think about it ?
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> ---
>>>>>>>>>>> Jannik Laval
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "What we can governs what we wish."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "We are all great at making mistakes."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Yesterday is a fact.
>>> Tomorrow is a possibility.
>>> Today is a challenge."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Problem solving should be concentrated on describing
> the problem in a way that is relevant for the solution."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
Opax is a very simple layer on top of a SAX Parser to let you dispatch  
XML tags to a hierarchy of classes, rather than just handling  
everything in one single method.

Opax is available in Pharo:

Gofer new
         squeaksource: 'XMLSupport';
         package: 'XML-Parser';
        squeaksource: 'OPAX';
        package: 'Opax';
        load.

So, you can subclass OPGenericElement and on the class side you can  
implement xmlTags to return the types of tags that you want this class  
to handle.

The result is that you get a typed tree instead of a string one.  
Afterwards you can do what you normally do with such an AST-like  
structure. I typically implement all "reify" methods in these classes.

Cheers,
Doru


On 3 May 2010, at 15:27, Alexandre Bergel wrote:

>> Perhaps having a look at Opax would ease a bit in getting from XML  
>> to objects in the image.
>
> I haven't checked the Store@SCG, but what is opax? It is not listed  
> in the tools section of the moose website. ScgBib does not know  
> about this word it apparently.
>
> Cheers,
> Alexandre
>
>>
>>
>> On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:
>>
>>> How the elements composing the AST can be represented. Maybe xml  
>>> queries are enough at that level...
>>>
>>> Alexandre
>>>
>>>
>>> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>>>
>>>> It is cost that I had in mind from the beginning. Now, we have  
>>>> CAnalyzer in place, so I guess it would be quite cheap to  
>>>> generalize it a bit and to hook it with the FAMIXFileAnchor to  
>>>> get an AST of it.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>>>
>>>>> well probably now with how much effort.
>>>>>
>>>>> stef
>>>>>
>>>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>>>
>>>>>> Exactly.
>>>>>>
>>>>>> Doru
>>>>>>
>>>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>>>
>>>>>>> A model originally created with inFusion, could then be  
>>>>>>> refined by loading srcML files, to add for example AST info.
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Another related idea is to not use srcML for the main  
>>>>>>>> parsing, but to keep it around for custom queries.
>>>>>>>>
>>>>>>>> So, we could still keep the current solution with inFusion  
>>>>>>>> for the main models, and have srcML for when we want to write  
>>>>>>>> queries that need access to AST.
>>>>>>>>
>>>>>>>> For example, if you do not have the right libraries, inFusion  
>>>>>>>> will not create annotation objects. If I would have access to  
>>>>>>>> the AST, I could write a query (even if it is expensive at  
>>>>>>>> first) that checks the AST of class for the existence of such  
>>>>>>>> annotations.
>>>>>>>>
>>>>>>>> I would use this. And maybe like this the srcML interface  
>>>>>>>> would grow in time and get better. What do you think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Doru
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>>>
>>>>>>>>> As Simon said, the type resolution in C is easy. In C++ it  
>>>>>>>>> is another beast.
>>>>>>>>>
>>>>>>>>> Alexandre
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>>>
>>>>>>>>>>> the problem is that meta model is different so you would  
>>>>>>>>>>> have to map everything.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>>>> sometimes not regular: i.e. similar things in the code does  
>>>>>>>>>> not have the same xml representation. This makes it  
>>>>>>>>>> cumbersome as it is not documented, so you have to decode  
>>>>>>>>>> the grammar from the xml and adapt to such irregularities.
>>>>>>>>>>
>>>>>>>>>> In the end, you still have to maintain a xml parser for  
>>>>>>>>>> each language and you still dont have control about what is  
>>>>>>>>>> extracted. And you have to do the type resolution :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Stef
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I am looking at srcML, and I see that it make XML files  
>>>>>>>>>>>> from Java and C++ source code.
>>>>>>>>>>>>
>>>>>>>>>>>> Since we use it for C source code, it should be possible  
>>>>>>>>>>>> to make it works with C++ and java.
>>>>>>>>>>>> This strategy allows us to not us a special tool for each  
>>>>>>>>>>>> language.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think about it ?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> ---
>>>>>>>>>>>> Jannik Laval
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Simon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>> --
>>>>>>>> www.tudorgirba.com
>>>>>>>>
>>>>>>>> "What we can governs what we wish."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "We are all great at making mistakes."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Yesterday is a fact.
>>>> Tomorrow is a possibility.
>>>> Today is a challenge."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Problem solving should be concentrated on describing
>> the problem in a way that is relevant for the solution."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Beauty is where we see it."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
Interesting. Thanks for pointing it out.

Cheers,
Alexandre


On 3 May 2010, at 13:48, Tudor Girba wrote:

> Opax is a very simple layer on top of a SAX Parser to let you  
> dispatch XML tags to a hierarchy of classes, rather than just  
> handling everything in one single method.
>
> Opax is available in Pharo:
>
> Gofer new
>        squeaksource: 'XMLSupport';
>        package: 'XML-Parser';
> squeaksource: 'OPAX';
> package: 'Opax';
> load.
>
> So, you can subclass OPGenericElement and on the class side you can  
> implement xmlTags to return the types of tags that you want this  
> class to handle.
>
> The result is that you get a typed tree instead of a string one.  
> Afterwards you can do what you normally do with such an AST-like  
> structure. I typically implement all "reify" methods in these classes.
>
> Cheers,
> Doru
>
>
> On 3 May 2010, at 15:27, Alexandre Bergel wrote:
>
>>> Perhaps having a look at Opax would ease a bit in getting from XML  
>>> to objects in the image.
>>
>> I haven't checked the Store@SCG, but what is opax? It is not listed  
>> in the tools section of the moose website. ScgBib does not know  
>> about this word it apparently.
>>
>> Cheers,
>> Alexandre
>>
>>>
>>>
>>> On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:
>>>
>>>> How the elements composing the AST can be represented. Maybe xml  
>>>> queries are enough at that level...
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>>>>
>>>>> It is cost that I had in mind from the beginning. Now, we have  
>>>>> CAnalyzer in place, so I guess it would be quite cheap to  
>>>>> generalize it a bit and to hook it with the FAMIXFileAnchor to  
>>>>> get an AST of it.
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>>>>
>>>>>> well probably now with how much effort.
>>>>>>
>>>>>> stef
>>>>>>
>>>>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>>>>
>>>>>>> Exactly.
>>>>>>>
>>>>>>> Doru
>>>>>>>
>>>>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>>>>
>>>>>>>> A model originally created with inFusion, could then be  
>>>>>>>> refined by loading srcML files, to add for example AST info.
>>>>>>>>
>>>>>>>> Alexandre
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Another related idea is to not use srcML for the main  
>>>>>>>>> parsing, but to keep it around for custom queries.
>>>>>>>>>
>>>>>>>>> So, we could still keep the current solution with inFusion  
>>>>>>>>> for the main models, and have srcML for when we want to  
>>>>>>>>> write queries that need access to AST.
>>>>>>>>>
>>>>>>>>> For example, if you do not have the right libraries,  
>>>>>>>>> inFusion will not create annotation objects. If I would have  
>>>>>>>>> access to the AST, I could write a query (even if it is  
>>>>>>>>> expensive at first) that checks the AST of class for the  
>>>>>>>>> existence of such annotations.
>>>>>>>>>
>>>>>>>>> I would use this. And maybe like this the srcML interface  
>>>>>>>>> would grow in time and get better. What do you think?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Doru
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>>>>
>>>>>>>>>> As Simon said, the type resolution in C is easy. In C++ it  
>>>>>>>>>> is another beast.
>>>>>>>>>>
>>>>>>>>>> Alexandre
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>>>>
>>>>>>>>>>>> the problem is that meta model is different so you would  
>>>>>>>>>>>> have to map everything.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>>>>> sometimes not regular: i.e. similar things in the code  
>>>>>>>>>>> does not have the same xml representation. This makes it  
>>>>>>>>>>> cumbersome as it is not documented, so you have to decode  
>>>>>>>>>>> the grammar from the xml and adapt to such irregularities.
>>>>>>>>>>>
>>>>>>>>>>> In the end, you still have to maintain a xml parser for  
>>>>>>>>>>> each language and you still dont have control about what  
>>>>>>>>>>> is extracted. And you have to do the type resolution :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Stef
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am looking at srcML, and I see that it make XML files  
>>>>>>>>>>>>> from Java and C++ source code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since we use it for C source code, it should be possible  
>>>>>>>>>>>>> to make it works with C++ and java.
>>>>>>>>>>>>> This strategy allows us to not us a special tool for  
>>>>>>>>>>>>> each language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think about it ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> Jannik Laval
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> www.tudorgirba.com
>>>>>>>>>
>>>>>>>>> "What we can governs what we wish."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "We are all great at making mistakes."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Yesterday is a fact.
>>>>> Tomorrow is a possibility.
>>>>> Today is a challenge."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Problem solving should be concentrated on describing
>>> the problem in a way that is relevant for the solution."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Beauty is where we see it."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Tudor Girba
This was the first thing I implemented in Java in 2000 as a project to  
show people in the company I worked at how it is possible to not have  
100 case statements in one method :)

Doru


On 3 May 2010, at 20:01, Alexandre Bergel wrote:

> Interesting. Thanks for pointing it out.
>
> Cheers,
> Alexandre
>
>
> On 3 May 2010, at 13:48, Tudor Girba wrote:
>
>> Opax is a very simple layer on top of a SAX Parser to let you  
>> dispatch XML tags to a hierarchy of classes, rather than just  
>> handling everything in one single method.
>>
>> Opax is available in Pharo:
>>
>> Gofer new
>>       squeaksource: 'XMLSupport';
>>       package: 'XML-Parser';
>> squeaksource: 'OPAX';
>> package: 'Opax';
>> load.
>>
>> So, you can subclass OPGenericElement and on the class side you can  
>> implement xmlTags to return the types of tags that you want this  
>> class to handle.
>>
>> The result is that you get a typed tree instead of a string one.  
>> Afterwards you can do what you normally do with such an AST-like  
>> structure. I typically implement all "reify" methods in these  
>> classes.
>>
>> Cheers,
>> Doru
>>
>>
>> On 3 May 2010, at 15:27, Alexandre Bergel wrote:
>>
>>>> Perhaps having a look at Opax would ease a bit in getting from  
>>>> XML to objects in the image.
>>>
>>> I haven't checked the Store@SCG, but what is opax? It is not  
>>> listed in the tools section of the moose website. ScgBib does not  
>>> know about this word it apparently.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>>
>>>>
>>>> On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:
>>>>
>>>>> How the elements composing the AST can be represented. Maybe xml  
>>>>> queries are enough at that level...
>>>>>
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>>>>>
>>>>>> It is cost that I had in mind from the beginning. Now, we have  
>>>>>> CAnalyzer in place, so I guess it would be quite cheap to  
>>>>>> generalize it a bit and to hook it with the FAMIXFileAnchor to  
>>>>>> get an AST of it.
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>>>>>
>>>>>>> well probably now with how much effort.
>>>>>>>
>>>>>>> stef
>>>>>>>
>>>>>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>>>>>
>>>>>>>> Exactly.
>>>>>>>>
>>>>>>>> Doru
>>>>>>>>
>>>>>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>>>>>
>>>>>>>>> A model originally created with inFusion, could then be  
>>>>>>>>> refined by loading srcML files, to add for example AST info.
>>>>>>>>>
>>>>>>>>> Alexandre
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Another related idea is to not use srcML for the main  
>>>>>>>>>> parsing, but to keep it around for custom queries.
>>>>>>>>>>
>>>>>>>>>> So, we could still keep the current solution with inFusion  
>>>>>>>>>> for the main models, and have srcML for when we want to  
>>>>>>>>>> write queries that need access to AST.
>>>>>>>>>>
>>>>>>>>>> For example, if you do not have the right libraries,  
>>>>>>>>>> inFusion will not create annotation objects. If I would  
>>>>>>>>>> have access to the AST, I could write a query (even if it  
>>>>>>>>>> is expensive at first) that checks the AST of class for the  
>>>>>>>>>> existence of such annotations.
>>>>>>>>>>
>>>>>>>>>> I would use this. And maybe like this the srcML interface  
>>>>>>>>>> would grow in time and get better. What do you think?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Doru
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>>>>>
>>>>>>>>>>> As Simon said, the type resolution in C is easy. In C++ it  
>>>>>>>>>>> is another beast.
>>>>>>>>>>>
>>>>>>>>>>> Alexandre
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> the problem is that meta model is different so you would  
>>>>>>>>>>>>> have to map everything.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>>>>>> sometimes not regular: i.e. similar things in the code  
>>>>>>>>>>>> does not have the same xml representation. This makes it  
>>>>>>>>>>>> cumbersome as it is not documented, so you have to decode  
>>>>>>>>>>>> the grammar from the xml and adapt to such irregularities.
>>>>>>>>>>>>
>>>>>>>>>>>> In the end, you still have to maintain a xml parser for  
>>>>>>>>>>>> each language and you still dont have control about what  
>>>>>>>>>>>> is extracted. And you have to do the type resolution :)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stef
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am looking at srcML, and I see that it make XML files  
>>>>>>>>>>>>>> from Java and C++ source code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since we use it for C source code, it should be  
>>>>>>>>>>>>>> possible to make it works with C++ and java.
>>>>>>>>>>>>>> This strategy allows us to not us a special tool for  
>>>>>>>>>>>>>> each language.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you think about it ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> Jannik Laval
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Simon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> www.tudorgirba.com
>>>>>>>>>>
>>>>>>>>>> "What we can governs what we wish."
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>> --
>>>>>>>> www.tudorgirba.com
>>>>>>>>
>>>>>>>> "We are all great at making mistakes."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Yesterday is a fact.
>>>>>> Tomorrow is a possibility.
>>>>>> Today is a challenge."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Problem solving should be concentrated on describing
>>>> the problem in a way that is relevant for the solution."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Beauty is where we see it."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Be rather willing to give than demanding to get."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: srcML for C++ and Java

Alexandre Bergel
:-)

Alexandre


On 3 May 2010, at 14:08, Tudor Girba wrote:

> This was the first thing I implemented in Java in 2000 as a project  
> to show people in the company I worked at how it is possible to not  
> have 100 case statements in one method :)
>
> Doru
>
>
> On 3 May 2010, at 20:01, Alexandre Bergel wrote:
>
>> Interesting. Thanks for pointing it out.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 3 May 2010, at 13:48, Tudor Girba wrote:
>>
>>> Opax is a very simple layer on top of a SAX Parser to let you  
>>> dispatch XML tags to a hierarchy of classes, rather than just  
>>> handling everything in one single method.
>>>
>>> Opax is available in Pharo:
>>>
>>> Gofer new
>>>      squeaksource: 'XMLSupport';
>>>      package: 'XML-Parser';
>>> squeaksource: 'OPAX';
>>> package: 'Opax';
>>> load.
>>>
>>> So, you can subclass OPGenericElement and on the class side you  
>>> can implement xmlTags to return the types of tags that you want  
>>> this class to handle.
>>>
>>> The result is that you get a typed tree instead of a string one.  
>>> Afterwards you can do what you normally do with such an AST-like  
>>> structure. I typically implement all "reify" methods in these  
>>> classes.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 3 May 2010, at 15:27, Alexandre Bergel wrote:
>>>
>>>>> Perhaps having a look at Opax would ease a bit in getting from  
>>>>> XML to objects in the image.
>>>>
>>>> I haven't checked the Store@SCG, but what is opax? It is not  
>>>> listed in the tools section of the moose website. ScgBib does not  
>>>> know about this word it apparently.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>>
>>>>>
>>>>> On 30 Apr 2010, at 17:18, Alexandre Bergel wrote:
>>>>>
>>>>>> How the elements composing the AST can be represented. Maybe  
>>>>>> xml queries are enough at that level...
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 30 Apr 2010, at 09:02, Tudor Girba wrote:
>>>>>>
>>>>>>> It is cost that I had in mind from the beginning. Now, we have  
>>>>>>> CAnalyzer in place, so I guess it would be quite cheap to  
>>>>>>> generalize it a bit and to hook it with the FAMIXFileAnchor to  
>>>>>>> get an AST of it.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> On 30 Apr 2010, at 09:06, Stéphane Ducasse wrote:
>>>>>>>
>>>>>>>> well probably now with how much effort.
>>>>>>>>
>>>>>>>> stef
>>>>>>>>
>>>>>>>> On Apr 30, 2010, at 7:34 AM, Tudor Girba wrote:
>>>>>>>>
>>>>>>>>> Exactly.
>>>>>>>>>
>>>>>>>>> Doru
>>>>>>>>>
>>>>>>>>> On 30 Apr 2010, at 05:47, Alexandre Bergel wrote:
>>>>>>>>>
>>>>>>>>>> A model originally created with inFusion, could then be  
>>>>>>>>>> refined by loading srcML files, to add for example AST info.
>>>>>>>>>>
>>>>>>>>>> Alexandre
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 29 Apr 2010, at 09:53, Tudor Girba wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Another related idea is to not use srcML for the main  
>>>>>>>>>>> parsing, but to keep it around for custom queries.
>>>>>>>>>>>
>>>>>>>>>>> So, we could still keep the current solution with inFusion  
>>>>>>>>>>> for the main models, and have srcML for when we want to  
>>>>>>>>>>> write queries that need access to AST.
>>>>>>>>>>>
>>>>>>>>>>> For example, if you do not have the right libraries,  
>>>>>>>>>>> inFusion will not create annotation objects. If I would  
>>>>>>>>>>> have access to the AST, I could write a query (even if it  
>>>>>>>>>>> is expensive at first) that checks the AST of class for  
>>>>>>>>>>> the existence of such annotations.
>>>>>>>>>>>
>>>>>>>>>>> I would use this. And maybe like this the srcML interface  
>>>>>>>>>>> would grow in time and get better. What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Doru
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28 Apr 2010, at 14:44, Alexandre Bergel wrote:
>>>>>>>>>>>
>>>>>>>>>>>> As Simon said, the type resolution in C is easy. In C++  
>>>>>>>>>>>> it is another beast.
>>>>>>>>>>>>
>>>>>>>>>>>> Alexandre
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 28 Apr 2010, at 04:47, Simon Denier wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 28 avr. 2010, at 10:36, Stéphane Ducasse wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> the problem is that meta model is different so you  
>>>>>>>>>>>>>> would have to map everything.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Besides, from what I have seen, the generated xml is  
>>>>>>>>>>>>> sometimes not regular: i.e. similar things in the code  
>>>>>>>>>>>>> does not have the same xml representation. This makes it  
>>>>>>>>>>>>> cumbersome as it is not documented, so you have to  
>>>>>>>>>>>>> decode the grammar from the xml and adapt to such  
>>>>>>>>>>>>> irregularities.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the end, you still have to maintain a xml parser for  
>>>>>>>>>>>>> each language and you still dont have control about what  
>>>>>>>>>>>>> is extracted. And you have to do the type resolution :)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Stef
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Apr 28, 2010, at 10:28 AM, Laval Jannik wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am looking at srcML, and I see that it make XML  
>>>>>>>>>>>>>>> files from Java and C++ source code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since we use it for C source code, it should be  
>>>>>>>>>>>>>>> possible to make it works with C++ and java.
>>>>>>>>>>>>>>> This strategy allows us to not us a special tool for  
>>>>>>>>>>>>>>> each language.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you think about it ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> Jannik Laval
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> www.tudorgirba.com
>>>>>>>>>>>
>>>>>>>>>>> "What we can governs what we wish."
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Moose-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> www.tudorgirba.com
>>>>>>>>>
>>>>>>>>> "We are all great at making mistakes."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "Yesterday is a fact.
>>>>>>> Tomorrow is a possibility.
>>>>>>> Today is a challenge."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Problem solving should be concentrated on describing
>>>>> the problem in a way that is relevant for the solution."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Beauty is where we see it."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Be rather willing to give than demanding to get."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev