Thread: [CEDET-devel] [PATCH] semantic-cpp.el: srecode-semantic-apply-tag-to-dict
Brought to you by:
zappo
From: Jan M. <jan...@un...> - 2008-11-04 21:02:01
Attachments:
srecode-cpp-apply-tag-to-dict.patch
|
Hi, I am currently writing an srecode application, which should work for object oriented languages. When testing my C++ templates, I had the impression, that some dictionary entries, specific to C++, should be added using the mode local override in the language support file. The attached patch implements this. The patch is not that useful without extended language templates (see below). I am not sure how to implement binary alternatives with srecode. Consequently the treatment of 'variable tags may not be optimal. If there is interest, I would also like to contribute the srecode application, the mode local override for Java and the extended templates for C++, Python and Java when they are ready. Kind regards, Jan |
From: Eric M. L. <er...@si...> - 2008-11-04 21:28:49
|
Hi, My brief look at your patch indicates you have the right idea here. For me to accept a patch of 10 or more "new" lines, you will need to have signed papers with the FSF for contributions to Emacs. You can send email to cop...@fs... specifying your intent, and they will help you out. As I'm sure you have noticed, the current SRecode support for regenerating tag code is proof-of-concept and does need help for many more languages. I'm excited to know this is proving useful. In your patch, you ask "Is there a better way?" Instead of a new section dictionary, you could simply set a value in the current dictionary for CONST which would be "const ". If it is not const, set CONST to be "". Eric >>> Jan Moringen <jan...@un...> seems to think that: >Hi, > >I am currently writing an srecode application, which should work for >object oriented languages. When testing my C++ templates, I had the >impression, that some dictionary entries, specific to C++, should be >added using the mode local override in the language support file. > >The attached patch implements this. The patch is not that useful without >extended language templates (see below). I am not sure how to implement >binary alternatives with srecode. Consequently the treatment of >'variable tags may not be optimal. > >If there is interest, I would also like to contribute the srecode >application, the mode local override for Java and the extended templates >for C++, Python and Java when they are ready. [ ... ] |
From: Jan M. <jan...@un...> - 2008-11-04 22:23:18
|
Hi. > My brief look at your patch indicates you have the right idea here. > For me to accept a patch of 10 or more "new" lines, you will need to > have signed papers with the FSF for contributions to Emacs. > > You can send email to cop...@fs... specifying your > intent, and they will help you out. I wasn't aware of that, but I will try to figure this out. > As I'm sure you have noticed, the current SRecode support for > regenerating tag code is proof-of-concept and does need help for many > more languages. I'm excited to know this is proving useful. Actually, the things I have tried so far worked pretty well. I will report any progress or problems as I go along. > In your patch, you ask "Is there a better way?" > > Instead of a new section dictionary, you could simply set a value in > the current dictionary for CONST which would be "const ". If it is > not const, set CONST to be "". If I understand your suggestion correctly, you would assign the actual text (or nothing) to the dictionary key. I thought of that as well, but it would prevent users from "fine-tuning" whitespaces and newlines surrounding the "const". That is why I went with the section dictionary. Maybe I am thinking overly general in this case. By the way, I unintendedly submitted the part which tries to store the fully qualified name using the FULLNAME key. As far as I can see, semantic-tag-full-name is not overloaded for any mode, so this part doesn't make any sense. (Unless I don't include the mode local implementation of semantic-tag-full-name, that is ;) Once I have taken care of those FSF papers, I will send an updated patch. Kind regards, Jan |
From: Eric M. L. <er...@si...> - 2008-11-05 02:06:38
|
>>> Jan Moringen <jan...@un...> seems to think that: >Hi. > >> My brief look at your patch indicates you have the right idea here. >> For me to accept a patch of 10 or more "new" lines, you will need to >> have signed papers with the FSF for contributions to Emacs. >> >> You can send email to cop...@fs... specifying your >> intent, and they will help you out. > >I wasn't aware of that, but I will try to figure this out. This is because CEDET will be integrated into Emacs sometime soon. You will need to send signed papers saying that you will give the copyright to code you write for Emacs to the FSF. You will also need to get something signed by your business or school where they claim no ownership. The first is easy. The second is not usually too difficult. >> As I'm sure you have noticed, the current SRecode support for >> regenerating tag code is proof-of-concept and does need help for many >> more languages. I'm excited to know this is proving useful. > >Actually, the things I have tried so far worked pretty well. I will >report any progress or problems as I go along. > >> In your patch, you ask "Is there a better way?" >> >> Instead of a new section dictionary, you could simply set a value in >> the current dictionary for CONST which would be "const ". If it is >> not const, set CONST to be "". > >If I understand your suggestion correctly, you would assign the actual >text (or nothing) to the dictionary key. I thought of that as well, but >it would prevent users from "fine-tuning" whitespaces and newlines >surrounding the "const". That is why I went with the section dictionary. >Maybe I am thinking overly general in this case. If "CONST" were added generically, then I would agree. In this case it is for C++ only. Since the templates you will write will be matched to the code adding CONST to the dictionary, it may not matter. You may need to distinguish from something that is const and a macro, as something like: #define FOO 1 is also const. >By the way, I unintendedly submitted the part which tries to store the >fully qualified name using the FULLNAME key. As far as I can see, >semantic-tag-full-name is not overloaded for any mode, so this part >doesn't make any sense. (Unless I don't include the mode local >implementation of semantic-tag-full-name, that is ;) [ ... ] The fullname function was added for the benefit of Java and, more specifically JDEE. I guess it was never used. It would make a lot of sense to add overloads for C++ also, as this is now derivable from the :parent attribute. I think there are some cases that could take advantage of this, such as code using semantic-analyze-unsplit-name perhaps. I'll have to investigate that concept. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Jan M. <jan...@un...> - 2009-01-14 23:45:58
|
> >> My brief look at your patch indicates you have the right idea here. > >> For me to accept a patch of 10 or more "new" lines, you will need to > >> have signed papers with the FSF for contributions to Emacs. > >> > >> You can send email to cop...@fs... specifying your > >> intent, and they will help you out. > > > >I wasn't aware of that, but I will try to figure this out. > > This is because CEDET will be integrated into Emacs sometime soon. > You will need to send signed papers saying that you will give the > copyright to code you write for Emacs to the FSF. You will also need > to get something signed by your business or school where they claim no > ownership. The first is easy. The second is not usually too > difficult. I finally worked everything out with my employer and the FSF. Attached is a reworked version of my original patch, which I would like to contribute. I also attached my templates for C++ mode to provide suggestions of how the added dictionary entries can be used. Kind regards, Jan |
From: Eric M. L. <er...@si...> - 2009-01-15 03:12:12
|
>>> Jan Moringen <jan...@un...> seems to think that: >> >> My brief look at your patch indicates you have the right idea here. >> >> For me to accept a patch of 10 or more "new" lines, you will need to >> >> have signed papers with the FSF for contributions to Emacs. >> >> >> >> You can send email to cop...@fs... specifying your >> >> intent, and they will help you out. >> > >> >I wasn't aware of that, but I will try to figure this out. >> >> This is because CEDET will be integrated into Emacs sometime soon. >> You will need to send signed papers saying that you will give the >> copyright to code you write for Emacs to the FSF. You will also need >> to get something signed by your business or school where they claim no >> ownership. The first is easy. The second is not usually too >> difficult. > >I finally worked everything out with my employer and the FSF. > >Attached is a reworked version of my original patch, which I would like >to contribute. I also attached my templates for C++ mode to provide >suggestions of how the added dictionary entries can be used. [ ... ] Your updated C++ support looks good, and solves some problems I knew were there but I hadn't gotten to yet. The updated C++ templates that go with it are also nice. Thanks. For your doxygen support file. Separating it out is a good idea. I added a comment writing tool a couple weeks back that was using the doxygen comments in C++, so this will be nice. I was also reading more about doxygen, as I personally don't use it much and needed to know more, and was reading that doxygen supports several languages other than C/C++. A side affect is that the doxygen.srt file could be written for "default" mode instead of "c++-mode". Based on the way you wrote it, I'm little would need to change other than the mode declaration, which is cool. A side effect is that it could then be accessed directly by the other doxygen supported language templates, such as PHP... if there were some PHP templates in SRecode that is. You had alluded to working on some SRecode based project. In case they overlap, you should know that I have some SRecode projects on my short todo list. If you'd like to take one over, feel free. They are: 1) Finish implementing "implement member functions" for C++. Thus, if you have a class, push a button to generate the code for any unimplemented methods. I got partway through, but haven't had time to finish it. 2) Port my ancient "cparse" header file maintainer program. Basically push a button in a c++ file, and it will update the header file w/ the prototype. Perhaps less "port", and more "recycle the idea". 3) Generated code out of COGRE for any support language. 4) Add base templates for more languages so "srecode-semantic-insert-tag" works. 5) Get EDE to use SRecode in more of it's Makefile generation. Thanks Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Daniel C. <dcl...@ya...> - 2009-01-15 09:50:07
|
> ... > they overlap, you should know that I have some SRecode projects on my > short todo list. If you'd like to take one over, feel free. They > are: > In the Emacs mailing list they are discussing participating in Google's „Summer of code“. Since CEDET will be an important part of Emacs, have you considered presenting some of these or bigger projects? Maybe the first project would be to integrate CEDET into Emacs. Daniel |
From: bread <bre...@gm...> - 2009-01-15 09:56:10
|
Wow, this sounds great!! And if CEDET presents "Summer of Code", I will be very glad to try to participate. But i'm afraid that this will need to Elisp a lot for which i'm only a beginner... On Thu, Jan 15, 2009 at 5:49 PM, Daniel Clemente <dcl...@ya...>wrote: > > > ... > > they overlap, you should know that I have some SRecode projects on my > > short todo list. If you'd like to take one over, feel free. They > > are: > > > > In the Emacs mailing list they are discussing participating in Google's > „Summer of code". Since CEDET will be an important part of Emacs, have you > considered presenting some of these or bigger projects? > Maybe the first project would be to integrate CEDET into Emacs. > > > Daniel > > -- Zhiqiu Kong (孔直秋) EDA Labs Dept. Computer Science & Technology Tsinghua University P.R China 100084 |
From: Eric M. L. <er...@si...> - 2009-01-15 12:57:45
|
>>> Daniel Clemente <dcl...@ya...> seems to think that: > >> they overlap, you should know that I have some SRecode >>projects on my> short todo list. If you'd like to take one over, >>feel free. They> are:> > > In the Emacs mailing list they are discussing participating in > Google's „Summer of code“. Since CEDET will be an important part of > Emacs, have you considered presenting some of these or bigger > projects? Maybe the first project would be to integrate CEDET into > Emacs. > [ ... ] That would be cool, though the bigger project that needs help is to re-write the C/C++ parser using wisent, and to design a "code" tag for functions in that parser. That alone will easily make things twice as fast parser-wise, if not more. Also, the integration of CEDET into Emacs thing is on someone's todo list in Emacs 24. Our directory structures conflict, the philosophy of mode-local.el which is very core to CEDET is contentious, and EIEIO has a compatibility bug I need to eliminate via a couple CEDET releases, so it is not as easy as it might seem. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Jan M. <jan...@un...> - 2009-01-19 03:57:11
|
> >I finally worked everything out with my employer and the FSF. > > > >Attached is a reworked version of my original patch, which I would like > >to contribute. I also attached my templates for C++ mode to provide > >suggestions of how the added dictionary entries can be used. > [ ... ] > > Your updated C++ support looks good, and solves some problems I knew > [...] > You had alluded to working on some SRecode based project. In case > they overlap, you should know that I have some SRecode projects on my > short todo list. If you'd like to take one over, feel free. They > are: The project I mentioned is a srecode application that generates implementation stubs for specified interfaces by traversing the hierarchy of base classes and collecting abstract method tags. Then it emits a class with appropriate parents and method stubs. I did some tests with C++ and think the concept could be useful. It does not currently deal with aspects like separation of prototypes and implementations in different files. > 1) Finish implementing "implement member functions" for C++. Thus, if > you have a class, push a button to generate the code for any > unimplemented methods. I got partway through, but haven't had time to > finish it. As I understand it, this goes pretty much in the same direction, the difference being that it would need to generate stubs for missing members instead of abstract members. > 2) Port my ancient "cparse" header file maintainer program. Basically > push a button in a c++ file, and it will update the header file w/ the > prototype. Perhaps less "port", and more "recycle the idea". I will have a look at cparse. > 3) Generated code out of COGRE for any support language. This sounds very interesting. Code generation from UML is a nice thing to have. Especially in combination with a powerful template system like srecode. However, to be useful, this would require more editing possibilities (add/remove members, set type, add/remove parameters) in the UML part of COGRE, right? > 4) Add base templates for more languages so > "srecode-semantic-insert-tag" works. > 5) Get EDE to use SRecode in more of it's Makefile generation. Sounds logical. I will certainly have a look at some of these projects. Is there a special place for experimental or work-in-progress code? Kind regards, Jan |
From: Eric M. L. <er...@si...> - 2009-01-19 21:10:13
|
>>> Jan Moringen <jan...@un...> seems to think that: >> >I finally worked everything out with my employer and the FSF. >> > >> >Attached is a reworked version of my original patch, which I would like >> >to contribute. I also attached my templates for C++ mode to provide >> >suggestions of how the added dictionary entries can be used. >> [ ... ] >> >> Your updated C++ support looks good, and solves some problems I knew >> [...] >> You had alluded to working on some SRecode based project. In case >> they overlap, you should know that I have some SRecode projects on my >> short todo list. If you'd like to take one over, feel free. They >> are: > >The project I mentioned is a srecode application that generates >implementation stubs for specified interfaces by traversing the >hierarchy of base classes and collecting abstract method tags. Then it >emits a class with appropriate parents and method stubs. There is some code in the smart-completion engine that does such a search, but filters instead on access conditions (public/private, etc). Hopefully there is something you can reuse there. >I did some tests with C++ and think the concept could be useful. It does >not currently deal with aspects like separation of prototypes and >implementations in different files. > >> 1) Finish implementing "implement member functions" for C++. Thus, if >> you have a class, push a button to generate the code for any >> unimplemented methods. I got partway through, but haven't had time to >> finish it. > >As I understand it, this goes pretty much in the same direction, the >difference being that it would need to generate stubs for missing >members instead of abstract members. This does sound mostly the same, and also worthwhile. There is probably a first-pass at this which would be "tell me what I need to do to this class still". These search criteria would then list all the unimplemented prototypes, and abstract methods that need to be dealt with, plus guesses as to where the new code may want to be inserted. This is also the hard part. Once you know all that, inserting the new code with the templates is easy. :) >> 2) Port my ancient "cparse" header file maintainer program. Basically >> push a button in a c++ file, and it will update the header file w/ the >> prototype. Perhaps less "port", and more "recycle the idea". > >I will have a look at cparse. Hmm. cparse is an old scary bit of code. I've been incorporating all my old ideas cparse into CEDET for years. Semantic is the "parse" replacement of cparse. EDE knows how to match up sources to header files. Srecode knows how to generate code from templates. srecode-document creates nice comments. The only missing bit is the command that links all the pieces together. So I guess all that is left is a command that matches the current tag to a prototype location, and updates it. >> 3) Generated code out of COGRE for any support language. > >This sounds very interesting. Code generation from UML is a nice thing >to have. Especially in combination with a powerful template system like >srecode. However, to be useful, this would require more editing >possibilities (add/remove members, set type, add/remove parameters) in >the UML part of COGRE, right? Indeed, that is the case. I stopped updated COGRE's UI when I realized I needed a better template insertion system than the hacks I had with tempo. It also needed better Semantic support. Those issues are mostly solved now though. I've had a C++ / Semanticdb project on my todo list for a long time. I always wanted to develop it from the ground-up using EDE and COGRE code generation in an effort to perfect the usability of the tools. I'll get to it someday. >> 4) Add base templates for more languages so >> "srecode-semantic-insert-tag" works. > >> 5) Get EDE to use SRecode in more of it's Makefile generation. > >Sounds logical. > >I will certainly have a look at some of these projects. Is there a >special place for experimental or work-in-progress code? [ ... ] Not really. I try stuff outside of CVS, and only check in the first draft when I'm mostly happy with the direction it may be going. We can work something out in CVS if there is need for collaboration of anything more than 1 or 2 files. Also, were you intending to check in your patches from earlier? I've been perfecting the dist/build process for the last few weeks and hope to wrap that up soon and make a distribution. Thanks Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Daniel C. <dcl...@ya...> - 2009-01-23 12:55:19
|
"Eric M. Ludlam" <er...@si...> writes: >>>> Daniel Clemente <dcl...@ya...> seems to think that: >> >>> they overlap, you should know that I have some SRecode >>>projects on my> short todo list. If you'd like to take one over, >>>feel free. They> are:> >> >> In the Emacs mailing list they are discussing participating in >> Google's „Summer of code“. Since CEDET will be an important part of >> Emacs, have you considered presenting some of these or bigger >> projects? Maybe the first project would be to integrate CEDET into >> Emacs. >> > [ ... ] > > That would be cool, though the bigger project that needs help is to > re-write the C/C++ parser using wisent, and to design a "code" tag for > functions in that parser. That alone will easily make things twice as > fast parser-wise, if not more. > > Also, the integration of CEDET into Emacs thing is on someone's todo > list in Emacs 24. Our directory structures conflict, the philosophy > of mode-local.el which is very core to CEDET is contentious, and EIEIO > has a compatibility bug I need to eliminate via a couple CEDET > releases, so it is not as easy as it might seem. > I have started a page where you can suggest this project, or others related to CEDET. http://www.emacswiki.org/emacs/SummerOfCode2009 Since „merging CEDET into Emacs“ will be a hot topic soon, an EmacsWiki page could be added to track the progress: objectives, what's done, what's missing, how to help, ... Greetings, Daniel |