[Moose-dev] Re: srcML for C++ and Java

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 >>>>>>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Moose-dev mailing list >>>>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Moose-dev mailing list >>>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> >>>>>>>>> "What we can governs what we wish." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "We are all great at making mistakes." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> 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 >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> 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 >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev