From yuuki.ari at gmail.com Tue Dec 2 00:08:10 2008 From: yuuki.ari at gmail.com (yuuki arisawa) Date: Tue, 2 Dec 2008 00:08:10 +0900 Subject: [Ginkgo-dev] New features in GCov for Eclipse In-Reply-To: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> References: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> Message-ID: <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> Hello Thank you for sending a patch! I'm sorry for late reply... Your modification seem to be very nice! especially in the third feature. > - Add Global coverage status in Coverage Navigator (it shows a global > coverage status + a coverage for each directories) That is the one of the big feature I want to use: ) I want to review your patch and merge it to main branch. But I am in busy now,so it may be fast to merge it yourself. And your following suggestions are interesting. In a Project with a lot of files, coverage calculation can takes a lot of > time > I think the reason why it takes a lot of time is gcov execution time. So, it may be effective that not parsing *.gcov files but parsing *.gcno and *.gcda files directory. - Add a stop target in the project; because eclipse cannot be used until > gcov builder is finished. > You are right,that should be background task. - The Builder file search is too slow, an other method should be used. It may be solved if *.gcno or *.gcda file include their source file's path. > - Possibility to use an external tools (for me it's an external make > target) that will execute gcov > Creating folder that linking to folder in the file system may help you. http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html If I've time I should be happy to help you on development of the plug-in, > but your source code comments cannot be read by a French guy like me :-) > Is it possible for you to translate source code comments in english? > I apologize to you to write comments in Japanese. So I promise you to translate these comments in English as soon as possible. Best Regards 2008/11/25 Frederic Belouin > Hello, > > I have modify your GCov for eclipse plugin > > Based on 0.22 tagged version I have: > - translate Builder Labels in English (thank to an automatic translator). > - Correct a bug in Navigator builder: Now Navigator view show the > coverage status > - Add Global coverage status in Coverage Navigator (it shows a global > coverage status + a coverage for each directories) > - Add Clean-up of Coverage Navigator when project is cleaned > > > I think there are some problems with the design of this coverage tool: > - Coverage builder and the coverage result extraction should be separate > using > > - Builder for gcov execution > > > - Error parser to retrieve result of coverage > > In a Project with a lot of files, coverage calculation can takes a lot of > time (with > 200 files it takes several hours) > > - Add a stop target in the project; because eclipse cannot be used until > gcov builder is finished. > > - The Builder file search is too slow, an other method should be used. > > - Possibility to use an external tools (for me it's an external make > target) that will execute gcov > > I like what you have done with this coverage tools. > > If I've time I should be happy to help you on development of the plug-in, > but your source code comments cannot be read by a French guy like me :-) > Is it possible for you to translate source code comments in english? > > Best Regards > > Fr?d?ric Belouin > -- Yuuki Arisawa yuuki.ari at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081202/48d926ae/attachment.htm From frederic.belouin at gmail.com Tue Dec 2 02:06:32 2008 From: frederic.belouin at gmail.com (Frederic Belouin) Date: Mon, 1 Dec 2008 18:06:32 +0100 Subject: [Ginkgo-dev] New features in GCov for Eclipse In-Reply-To: <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> References: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> Message-ID: <21fb03090812010906g214ac7b5qf5b6316454cb846b@mail.gmail.com> Hello yuuki, (Is it your name?) I don't know when I can help you for merge. But I should be happy If I found time to do this. What is the procedure to do this stuff? I also see that you've got several source code branches; what branch should I use? what is the difference between org.ginkgo.gcov.ui.e32 and org.ginkgo.gcov.ui.e33? Thank You Best Regards Frederic Belouin 2008/12/1 yuuki arisawa > > Hello > > Thank you for sending a patch! > I'm sorry for late reply... > > Your modification seem to be very nice! > especially in the third feature. > > - Add Global coverage status in Coverage Navigator (it shows a global > > coverage status + a coverage for each directories) > That is the one of the big feature I want to use: ) > > I want to review your patch and merge it to main branch. > But I am in busy now,so it may be fast to merge it yourself. > > And your following suggestions are interesting. > > In a Project with a lot of files, coverage calculation can takes a lot of >> time >> > I think the reason why it takes a lot of time is gcov execution time. > So, it may be effective that not parsing *.gcov files but parsing *.gcno > and *.gcda files directory. > > - Add a stop target in the project; because eclipse cannot be used until >> gcov builder is finished. >> > You are right,that should be background task. > > - The Builder file search is too slow, an other method should be used. > > It may be solved if *.gcno or *.gcda file include their source file's > path. > > >> - Possibility to use an external tools (for me it's an external make >> target) that will execute gcov >> > Creating folder that linking to folder in the file system may help you. > > http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html > > http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html > > If I've time I should be happy to help you on development of the plug-in, >> but your source code comments cannot be read by a French guy like me :-) >> > Is it possible for you to translate source code comments in english? >> > I apologize to you to write comments in Japanese. > So I promise you to translate these comments in English as soon as > possible. > > Best Regards > > 2008/11/25 Frederic Belouin > > Hello, >> >> I have modify your GCov for eclipse plugin >> >> Based on 0.22 tagged version I have: >> - translate Builder Labels in English (thank to an automatic >> translator). >> - Correct a bug in Navigator builder: Now Navigator view show the >> coverage status >> - Add Global coverage status in Coverage Navigator (it shows a global >> coverage status + a coverage for each directories) >> - Add Clean-up of Coverage Navigator when project is cleaned >> >> >> I think there are some problems with the design of this coverage tool: >> - Coverage builder and the coverage result extraction should be separate >> using >> >> - Builder for gcov execution >> >> >> - Error parser to retrieve result of coverage >> >> In a Project with a lot of files, coverage calculation can takes a lot of >> time (with > 200 files it takes several hours) >> >> - Add a stop target in the project; because eclipse cannot be used until >> gcov builder is finished. >> >> - The Builder file search is too slow, an other method should be used. >> >> - Possibility to use an external tools (for me it's an external make >> target) that will execute gcov >> >> I like what you have done with this coverage tools. >> >> If I've time I should be happy to help you on development of the plug-in, >> but your source code comments cannot be read by a French guy like me :-) >> Is it possible for you to translate source code comments in english? >> >> Best Regards >> >> Fr?d?ric Belouin >> > > > > -- > Yuuki Arisawa > yuuki.ari at gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081201/381eca24/attachment.htm From yuuki.ari at gmail.com Wed Dec 3 22:26:59 2008 From: yuuki.ari at gmail.com (yuuki arisawa) Date: Wed, 3 Dec 2008 22:26:59 +0900 Subject: [Ginkgo-dev] New features in GCov for Eclipse In-Reply-To: <21fb03090812010906g214ac7b5qf5b6316454cb846b@mail.gmail.com> References: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> <21fb03090812010906g214ac7b5qf5b6316454cb846b@mail.gmail.com> Message-ID: <3a6ca8920812030526j1c6c11d0s92af089f6225cde@mail.gmail.com> Hello Frederic. This is yuuki. I'm happy to hear that you are willing to help me. Of course it will be all right to help me whenever you have enough time. I try to answer your questions. I also see that you've got several source code branches; > what branch should I use? > There is three branches in the repository. The first and oldest branch is /trunk. This was the branch I used to developped. Version 0.2.2 is based on this branch. The differences between 0.2.2(rev.68) and trunk(rev.90) are coverage history view and bug fix. The second is /branches/monamour. This is the branch where MURANAKA ported this plug-in to Eclipse 3.2?Callisto?. It's based on trunk(rev.26). The last is /branches/for_merge. This is the branch where I tried to integrate /trunk and /branches/monamour. I separate the source which depend on eclipse version (org.ginkgo.gcov.ui.e33 and org.ginkgo.gcov.ui.e32) and the source which independ from eclipse version (org.ginkgo.gcov). So now,we can get two versions of source(for Eclipse 3.2 and for Eclipse 3.3+) from repository, and the sources are shared each. If you want to get the source for Eclipse 3.3,check out org.ginkgo.gcov, org.ginkgo.gcov.ui.e33, org.ginkgo.gcov.feature.e33, and org.ginkgo.gcov.update.e33, from /branches/for_merge. But the repository become very confusing,you know. And it seems hard to maintain. So I want smart idea to resolve it. Do you have any idea? Thank You Best Regards 2008/12/2 Frederic Belouin > Hello yuuki, (Is it your name?) > > I don't know when I can help you for merge. > But I should be happy If I found time to do this. > > What is the procedure to do this stuff? > > > I also see that you've got several source code branches; > what branch should I use? > > what is the difference between org.ginkgo.gcov.ui.e32 and > org.ginkgo.gcov.ui.e33? > > Thank You > > Best Regards > > Frederic Belouin > > > 2008/12/1 yuuki arisawa > > >> Hello >> >> Thank you for sending a patch! >> I'm sorry for late reply... >> >> Your modification seem to be very nice! >> especially in the third feature. >> > - Add Global coverage status in Coverage Navigator (it shows a global >> > coverage status + a coverage for each directories) >> That is the one of the big feature I want to use: ) >> >> I want to review your patch and merge it to main branch. >> But I am in busy now,so it may be fast to merge it yourself. >> >> And your following suggestions are interesting. >> >> In a Project with a lot of files, coverage calculation can takes a lot of >>> time >>> >> I think the reason why it takes a lot of time is gcov execution time. >> So, it may be effective that not parsing *.gcov files but parsing *.gcno >> and *.gcda files directory. >> >> - Add a stop target in the project; because eclipse cannot be used until >>> gcov builder is finished. >>> >> You are right,that should be background task. >> >> - The Builder file search is too slow, an other method should be used. >> >> It may be solved if *.gcno or *.gcda file include their source file's >> path. >> >> >>> - Possibility to use an external tools (for me it's an external make >>> target) that will execute gcov >>> >> Creating folder that linking to folder in the file system may help you. >> >> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html >> >> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html >> >> If I've time I should be happy to help you on development of the plug-in, >>> but your source code comments cannot be read by a French guy like me :-) >>> >> Is it possible for you to translate source code comments in english? >>> >> I apologize to you to write comments in Japanese. >> So I promise you to translate these comments in English as soon as >> possible. >> >> Best Regards >> >> 2008/11/25 Frederic Belouin >> >> Hello, >>> >>> I have modify your GCov for eclipse plugin >>> >>> Based on 0.22 tagged version I have: >>> - translate Builder Labels in English (thank to an automatic >>> translator). >>> - Correct a bug in Navigator builder: Now Navigator view show the >>> coverage status >>> - Add Global coverage status in Coverage Navigator (it shows a global >>> coverage status + a coverage for each directories) >>> - Add Clean-up of Coverage Navigator when project is cleaned >>> >>> >>> I think there are some problems with the design of this coverage tool: >>> - Coverage builder and the coverage result extraction should be separate >>> using >>> >>> - Builder for gcov execution >>> >>> >>> - Error parser to retrieve result of coverage >>> >>> In a Project with a lot of files, coverage calculation can takes a lot of >>> time (with > 200 files it takes several hours) >>> >>> - Add a stop target in the project; because eclipse cannot be used until >>> gcov builder is finished. >>> >>> - The Builder file search is too slow, an other method should be used. >>> >>> - Possibility to use an external tools (for me it's an external make >>> target) that will execute gcov >>> >>> I like what you have done with this coverage tools. >>> >>> If I've time I should be happy to help you on development of the plug-in, >>> but your source code comments cannot be read by a French guy like me :-) >>> Is it possible for you to translate source code comments in english? >>> >>> Best Regards >>> >>> Fr?d?ric Belouin >>> >> >> >> >> -- >> Yuuki Arisawa >> yuuki.ari at gmail.com >> >> > -- Yuuki Arisawa yuuki.ari at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081203/5dedd5a3/attachment.htm From frederic.belouin at gmail.com Thu Dec 4 01:21:41 2008 From: frederic.belouin at gmail.com (Frederic Belouin) Date: Wed, 3 Dec 2008 17:21:41 +0100 Subject: [Ginkgo-dev] New features in GCov for Eclipse In-Reply-To: <3a6ca8920812030526j1c6c11d0s92af089f6225cde@mail.gmail.com> References: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> <21fb03090812010906g214ac7b5qf5b6316454cb846b@mail.gmail.com> <3a6ca8920812030526j1c6c11d0s92af089f6225cde@mail.gmail.com> Message-ID: <21fb03090812030821y22568567y7dd519354ef3ff3e@mail.gmail.com> Hello yuuki, I'm not very familiar with SVN. I propose to use eclipse based work areas: /branches/eclipse3.2.x/ /branches/eclipse3.2.x/org.ginkgo.gcov /branches/eclipse3.2.x/org.ginkgo.gcov.ui /branches/eclipse3.2.x/org.ginkgo.gcov.feature /branches/eclipse3.2.x/org.ginkgo.gcov.update /branches/eclipse3.3/ /branches/eclipse3.3.x/org.ginkgo.gcov /branches/eclipse3.3.x/org.ginkgo.gcov.ui /branches/eclipse3.3.x/org.ginkgo.gcov.feature /branches/eclipse3.3.x/org.ginkgo.gcov.update /branches/eclipse3.4/ /branches/eclipse3.4.x/org.ginkgo.gcov /branches/eclipse3.4.x/org.ginkgo.gcov.ui /branches/eclipse3.4.x/org.ginkgo.gcov.feature /branches/eclipse3.4.x/org.ginkgo.gcov.update ... /trunk/release/ (a link to the latest release) About ginko version, you should use: for beta release: 0.3.2.betaY -->for eclipse 3.2 0.3.3.betaY -->for eclipse 3.3 0.3.4.betaY -->for eclipse 3.4 for release candidate: 0.3.2.rcY -->for eclipse 3.2 0.3.3.rcY -->for eclipse 3.3 0.3.4.rcY -->for eclipse 3.4 for release: 3.2.Y -->for eclipse 3.2 3.3.Y -->for eclipse 3.3 3.4.Y -->for eclipse 3.4 Advantage, you can easily merge modification on several plug-in versions You don't need to create directories for minor versions What do you think about this? Best Regards Frederic Belouin 2008/12/3 yuuki arisawa > > Hello Frederic. > This is yuuki. > > I'm happy to hear that you are willing to help me. > Of course it will be all right to help me whenever you have enough time. > > I try to answer your questions. > > I also see that you've got several source code branches; >> what branch should I use? >> > There is three branches in the repository. > > The first and oldest branch is /trunk. > This was the branch I used to developped. > Version 0.2.2 is based on this branch. > The differences between 0.2.2(rev.68) and trunk(rev.90) are coverage > history view and bug fix. > > The second is /branches/monamour. > This is the branch where MURANAKA ported this plug-in to Eclipse > 3.2?Callisto?. > It's based on trunk(rev.26). > > The last is /branches/for_merge. > This is the branch where I tried to integrate /trunk and > /branches/monamour. > I separate the source which depend on eclipse version > (org.ginkgo.gcov.ui.e33 and org.ginkgo.gcov.ui.e32) > and the source which independ from eclipse version > (org.ginkgo.gcov). > > So now,we can get two versions of source(for Eclipse 3.2 and for Eclipse > 3.3+) from repository, > and the sources are shared each. > If you want to get the source for Eclipse 3.3,check out > org.ginkgo.gcov, > org.ginkgo.gcov.ui.e33, > org.ginkgo.gcov.feature.e33, and > org.ginkgo.gcov.update.e33, > from /branches/for_merge. > > But the repository become very confusing,you know. > And it seems hard to maintain. > > So I want smart idea to resolve it. > Do you have any idea? > > Thank You > Best Regards > > 2008/12/2 Frederic Belouin > > Hello yuuki, (Is it your name?) >> >> I don't know when I can help you for merge. >> But I should be happy If I found time to do this. >> >> What is the procedure to do this stuff? >> >> >> I also see that you've got several source code branches; >> what branch should I use? >> >> what is the difference between org.ginkgo.gcov.ui.e32 and >> org.ginkgo.gcov.ui.e33? >> >> Thank You >> >> Best Regards >> >> Frederic Belouin >> >> >> 2008/12/1 yuuki arisawa >> >> >>> Hello >>> >>> Thank you for sending a patch! >>> I'm sorry for late reply... >>> >>> Your modification seem to be very nice! >>> especially in the third feature. >>> > - Add Global coverage status in Coverage Navigator (it shows a global >>> > coverage status + a coverage for each directories) >>> That is the one of the big feature I want to use: ) >>> >>> I want to review your patch and merge it to main branch. >>> But I am in busy now,so it may be fast to merge it yourself. >>> >>> And your following suggestions are interesting. >>> >>> In a Project with a lot of files, coverage calculation can takes a lot of >>>> time >>>> >>> I think the reason why it takes a lot of time is gcov execution time. >>> So, it may be effective that not parsing *.gcov files but parsing *.gcno >>> and *.gcda files directory. >>> >>> - Add a stop target in the project; because eclipse cannot be used until >>>> gcov builder is finished. >>>> >>> You are right,that should be background task. >>> >>> - The Builder file search is too slow, an other method should be used. >>> >>> It may be solved if *.gcno or *.gcda file include their source file's >>> path. >>> >>> >>>> - Possibility to use an external tools (for me it's an external make >>>> target) that will execute gcov >>>> >>> Creating folder that linking to folder in the file system may help you. >>> >>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html >>> >>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html >>> >>> If I've time I should be happy to help you on development of the >>>> plug-in, but your source code comments cannot be read by a French guy like >>>> me :-) >>>> >>> Is it possible for you to translate source code comments in english? >>>> >>> I apologize to you to write comments in Japanese. >>> So I promise you to translate these comments in English as soon as >>> possible. >>> >>> Best Regards >>> >>> 2008/11/25 Frederic Belouin >>> >>> Hello, >>>> >>>> I have modify your GCov for eclipse plugin >>>> >>>> Based on 0.22 tagged version I have: >>>> - translate Builder Labels in English (thank to an automatic >>>> translator). >>>> - Correct a bug in Navigator builder: Now Navigator view show the >>>> coverage status >>>> - Add Global coverage status in Coverage Navigator (it shows a global >>>> coverage status + a coverage for each directories) >>>> - Add Clean-up of Coverage Navigator when project is cleaned >>>> >>>> >>>> I think there are some problems with the design of this coverage tool: >>>> - Coverage builder and the coverage result extraction should be separate >>>> using >>>> >>>> - Builder for gcov execution >>>> >>>> >>>> - Error parser to retrieve result of coverage >>>> >>>> In a Project with a lot of files, coverage calculation can takes a lot >>>> of time (with > 200 files it takes several hours) >>>> >>>> - Add a stop target in the project; because eclipse cannot be used until >>>> gcov builder is finished. >>>> >>>> - The Builder file search is too slow, an other method should be used. >>>> >>>> - Possibility to use an external tools (for me it's an external make >>>> target) that will execute gcov >>>> >>>> I like what you have done with this coverage tools. >>>> >>>> If I've time I should be happy to help you on development of the >>>> plug-in, but your source code comments cannot be read by a French guy like >>>> me :-) >>>> Is it possible for you to translate source code comments in english? >>>> >>>> Best Regards >>>> >>>> Fr?d?ric Belouin >>>> >>> >>> >>> >>> -- >>> Yuuki Arisawa >>> yuuki.ari at gmail.com >>> >>> >> > > > -- > Yuuki Arisawa > yuuki.ari at gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081203/e88ed203/attachment.htm From yuuki.ari at gmail.com Fri Dec 5 00:23:30 2008 From: yuuki.ari at gmail.com (yuuki arisawa) Date: Fri, 5 Dec 2008 00:23:30 +0900 Subject: [Ginkgo-dev] =?GB2312?B?peql3aW4pcil6qTOmIuzyaTLpMSkpKTGpM6ktM/g1YShoUZ3ZDogTmV3IGY=?= =?GB2312?B?ZWF0dXJlcyBpbiBHQ292IGZvciBFY2xpcHNl?= Message-ID: <3a6ca8920812040723k26b3b5e9pea59ea5c8cd4121e@mail.gmail.com> ?????????? ???????????? gcov plugin ???????????? ???????????????????????????????? ???}???????????? ???????`???`?????????????????????????????????????????????????????????????????????????? ?????z?????????????????????? ???????????`?????????H???????????????????????????????????????? ???????????????`???????????????? ?????????_?????????????????`?????????? ?????????????????????????????????I???????????????? ?Y?????????? /branches/for_merge ???????????????????????????? ???????????????????????}???????????????????????????? ?????????????? Eclipse?????`???????????????????`???? ?e???????????????????x????org.ginkgo.gcov.ui.e33,org.ginkgo.gcov.ui.e32?? ??????????????(org.ginkgo.gcov)???????????????????????????? ???????????????????}?????????????????????????????????????? ?????`?????`?????????????????`???????????}???????????????? ?????_?k???????????????????????????????????????????? ?????????????????}???????? ??????????????(org.ginkgo.gcov)?????????I???????????????????????????????? ?`?????????????????`???????????????????????????????????????????????????? ??????????????????svn:external???????????????????????????????????}???????????Q?????????? ?????????????????????????????e???????????????????? ?????????`???????H?????????????????????????????????????????????????????????????? ???????????????????????????????}?????????????????? ????????????????????subversion????git???????\???Q???????????????????????????? ?????????????? ????????subversion???????????\???????????????????????????? ?L???????????????????????????? ???????????????????????????? ---------- Forwarded message ---------- ??????: Frederic Belouin Date: 2008/12/4 Subject: Re: New features in GCov for Eclipse To: yuuki arisawa Cc: ginkgo-dev at lists.sourceforge.jp Hello yuuki, I'm not very familiar with SVN. I propose to use eclipse based work areas: /branches/eclipse3.2.x/ /branches/eclipse3.2.x/org.ginkgo.gcov /branches/eclipse3.2.x/org.ginkgo.gcov.ui /branches/eclipse3.2.x/org.ginkgo.gcov.feature /branches/eclipse3.2.x/org.ginkgo.gcov.update /branches/eclipse3.3/ /branches/eclipse3.3.x/org.ginkgo.gcov /branches/eclipse3.3.x/org.ginkgo.gcov.ui /branches/eclipse3.3.x/org.ginkgo.gcov.feature /branches/eclipse3.3.x/org.ginkgo.gcov.update /branches/eclipse3.4/ /branches/eclipse3.4.x/org.ginkgo.gcov /branches/eclipse3.4.x/org.ginkgo.gcov.ui /branches/eclipse3.4.x/org.ginkgo.gcov.feature /branches/eclipse3.4.x/org.ginkgo.gcov.update ... /trunk/release/ (a link to the latest release) About ginko version, you should use: for beta release: 0.3.2.betaY -->for eclipse 3.2 0.3.3.betaY -->for eclipse 3.3 0.3.4.betaY -->for eclipse 3.4 for release candidate: 0.3.2.rcY -->for eclipse 3.2 0.3.3.rcY -->for eclipse 3.3 0.3.4.rcY -->for eclipse 3.4 for release: 3.2.Y -->for eclipse 3.2 3.3.Y -->for eclipse 3.3 3.4.Y -->for eclipse 3.4 Advantage, you can easily merge modification on several plug-in versions You don't need to create directories for minor versions What do you think about this? Best Regards Frederic Belouin 2008/12/3 yuuki arisawa > Hello Frederic. > This is yuuki. > > I'm happy to hear that you are willing to help me. > Of course it will be all right to help me whenever you have enough time. > > I try to answer your questions. > > I also see that you've got several source code branches; >> what branch should I use? >> > There is three branches in the repository. > > The first and oldest branch is /trunk. > This was the branch I used to developped. > Version 0.2.2 is based on this branch. > The differences between 0.2.2(rev.68) and trunk(rev.90) are coverage > history view and bug fix. > > The second is /branches/monamour. > This is the branch where MURANAKA ported this plug-in to Eclipse > 3.2??Callisto??. > It's based on trunk(rev.26). > > The last is /branches/for_merge. > This is the branch where I tried to integrate /trunk and > /branches/monamour. > I separate the source which depend on eclipse version > (org.ginkgo.gcov.ui.e33 and org.ginkgo.gcov.ui.e32) > and the source which independ from eclipse version > (org.ginkgo.gcov). > > So now,we can get two versions of source(for Eclipse 3.2 and for Eclipse > 3.3+) from repository, > and the sources are shared each. > If you want to get the source for Eclipse 3.3,check out > org.ginkgo.gcov, > org.ginkgo.gcov.ui.e33, > org.ginkgo.gcov.feature.e33, and > org.ginkgo.gcov.update.e33, > from /branches/for_merge. > > But the repository become very confusing,you know. > And it seems hard to maintain. > > So I want smart idea to resolve it. > Do you have any idea? > > Thank You > Best Regards > > 2008/12/2 Frederic Belouin > > Hello yuuki, (Is it your name?) >> >> I don't know when I can help you for merge. >> But I should be happy If I found time to do this. >> >> What is the procedure to do this stuff? >> >> >> I also see that you've got several source code branches; >> what branch should I use? >> >> what is the difference between org.ginkgo.gcov.ui.e32 and >> org.ginkgo.gcov.ui.e33? >> >> Thank You >> >> Best Regards >> >> Frederic Belouin >> >> >> 2008/12/1 yuuki arisawa >> >> >>> Hello >>> >>> Thank you for sending a patch! >>> I'm sorry for late reply... >>> >>> Your modification seem to be very nice! >>> especially in the third feature. >>> > - Add Global coverage status in Coverage Navigator (it shows a global >>> > coverage status + a coverage for each directories) >>> That is the one of the big feature I want to use: ) >>> >>> I want to review your patch and merge it to main branch. >>> But I am in busy now,so it may be fast to merge it yourself. >>> >>> And your following suggestions are interesting. >>> >>> In a Project with a lot of files, coverage calculation can takes a lot of >>>> time >>>> >>> I think the reason why it takes a lot of time is gcov execution time. >>> So, it may be effective that not parsing *.gcov files but parsing *.gcno >>> and *.gcda files directory. >>> >>> - Add a stop target in the project; because eclipse cannot be used until >>>> gcov builder is finished. >>>> >>> You are right,that should be background task. >>> >>> - The Builder file search is too slow, an other method should be used. >>> >>> It may be solved if *.gcno or *.gcda file include their source file's >>> path. >>> >>> >>>> - Possibility to use an external tools (for me it's an external make >>>> target) that will execute gcov >>>> >>> Creating folder that linking to folder in the file system may help you. >>> >>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html >>> >>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html >>> >>> If I've time I should be happy to help you on development of the >>>> plug-in, but your source code comments cannot be read by a French guy like >>>> me :-) >>>> >>> Is it possible for you to translate source code comments in english? >>>> >>> I apologize to you to write comments in Japanese. >>> So I promise you to translate these comments in English as soon as >>> possible. >>> >>> Best Regards >>> >>> 2008/11/25 Frederic Belouin >>> >>> Hello, >>>> >>>> I have modify your GCov for eclipse plugin >>>> >>>> Based on 0.22 tagged version I have: >>>> - translate Builder Labels in English (thank to an automatic >>>> translator). >>>> - Correct a bug in Navigator builder: Now Navigator view show the >>>> coverage status >>>> - Add Global coverage status in Coverage Navigator (it shows a global >>>> coverage status + a coverage for each directories) >>>> - Add Clean-up of Coverage Navigator when project is cleaned >>>> >>>> >>>> I think there are some problems with the design of this coverage tool: >>>> - Coverage builder and the coverage result extraction should be separate >>>> using >>>> >>>> - Builder for gcov execution >>>> >>>> >>>> - Error parser to retrieve result of coverage >>>> >>>> In a Project with a lot of files, coverage calculation can takes a lot >>>> of time (with > 200 files it takes several hours) >>>> >>>> - Add a stop target in the project; because eclipse cannot be used until >>>> gcov builder is finished. >>>> >>>> - The Builder file search is too slow, an other method should be used. >>>> >>>> - Possibility to use an external tools (for me it's an external make >>>> target) that will execute gcov >>>> >>>> I like what you have done with this coverage tools. >>>> >>>> If I've time I should be happy to help you on development of the >>>> plug-in, but your source code comments cannot be read by a French guy like >>>> me :-) >>>> Is it possible for you to translate source code comments in english? >>>> >>>> Best Regards >>>> >>>> Fr??d??ric Belouin >>>> >>> >>> >>> >>> -- >>> Yuuki Arisawa >>> yuuki.ari at gmail.com >>> >>> >> > > > -- > Yuuki Arisawa > yuuki.ari at gmail.com > > -- Yuuki Arisawa yuuki.ari at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081205/f2d82f86/attachment.htm From yuuki.ari at gmail.com Tue Dec 16 00:26:27 2008 From: yuuki.ari at gmail.com (yuuki arisawa) Date: Tue, 16 Dec 2008 00:26:27 +0900 Subject: [Ginkgo-dev] New features in GCov for Eclipse In-Reply-To: <21fb03090812030821y22568567y7dd519354ef3ff3e@mail.gmail.com> References: <21fb03090811240824r777a4258l3dca60d6e39daf7e@mail.gmail.com> <3a6ca8920812010708x2c51fbb4i48cf453d449c5cfc@mail.gmail.com> <21fb03090812010906g214ac7b5qf5b6316454cb846b@mail.gmail.com> <3a6ca8920812030526j1c6c11d0s92af089f6225cde@mail.gmail.com> <21fb03090812030821y22568567y7dd519354ef3ff3e@mail.gmail.com> Message-ID: <3a6ca8920812150726oe51e527i662e666252b1b782@mail.gmail.com> Hi Frederic, I started to clean up the plug-in repository. And I tried using "git" so that I can maintain easily. It's works better for me than "svn". I applied your patch and now you can use repository to develop your new features. #And I can do some tasks,like source code comments translation too:-) So I want you to join us as committer. Could you create "sourceforge.jp"'s account and tell me the account? Best Regards Yuuki Arisawa 2008/12/4 Frederic Belouin > Hello yuuki, > > I'm not very familiar with SVN. > I propose to use eclipse based work areas: > > /branches/eclipse3.2.x/ > /branches/eclipse3.2.x/org.ginkgo.gcov > /branches/eclipse3.2.x/org.ginkgo.gcov.ui > /branches/eclipse3.2.x/org.ginkgo.gcov.feature > /branches/eclipse3.2.x/org.ginkgo.gcov.update > > /branches/eclipse3.3/ > /branches/eclipse3.3.x/org.ginkgo.gcov > /branches/eclipse3.3.x/org.ginkgo.gcov.ui > /branches/eclipse3.3.x/org.ginkgo.gcov.feature > /branches/eclipse3.3.x/org.ginkgo.gcov.update > > > /branches/eclipse3.4/ > /branches/eclipse3.4.x/org.ginkgo.gcov > /branches/eclipse3.4.x/org.ginkgo.gcov.ui > /branches/eclipse3.4.x/org.ginkgo.gcov.feature > /branches/eclipse3.4.x/org.ginkgo.gcov.update > > ... > > /trunk/release/ (a link to the latest release) > > About ginko version, you should use: > > for beta release: > 0.3.2.betaY -->for eclipse 3.2 > 0.3.3.betaY -->for eclipse 3.3 > 0.3.4.betaY -->for eclipse 3.4 > > for release candidate: > 0.3.2.rcY -->for eclipse 3.2 > 0.3.3.rcY -->for eclipse 3.3 > 0.3.4.rcY -->for eclipse 3.4 > > for release: > 3.2.Y -->for eclipse 3.2 > 3.3.Y -->for eclipse 3.3 > 3.4.Y -->for eclipse 3.4 > > Advantage, you can easily merge modification on several plug-in versions > You don't need to create directories for minor versions > > > What do you think about this? > > Best Regards > Frederic Belouin > > > 2008/12/3 yuuki arisawa > > >> Hello Frederic. >> This is yuuki. >> >> I'm happy to hear that you are willing to help me. >> Of course it will be all right to help me whenever you have enough time. >> >> I try to answer your questions. >> >> I also see that you've got several source code branches; >>> what branch should I use? >>> >> There is three branches in the repository. >> >> The first and oldest branch is /trunk. >> This was the branch I used to developped. >> Version 0.2.2 is based on this branch. >> The differences between 0.2.2(rev.68) and trunk(rev.90) are coverage >> history view and bug fix. >> >> The second is /branches/monamour. >> This is the branch where MURANAKA ported this plug-in to Eclipse >> 3.2?Callisto?. >> It's based on trunk(rev.26). >> >> The last is /branches/for_merge. >> This is the branch where I tried to integrate /trunk and >> /branches/monamour. >> I separate the source which depend on eclipse version >> (org.ginkgo.gcov.ui.e33 and org.ginkgo.gcov.ui.e32) >> and the source which independ from eclipse version >> (org.ginkgo.gcov). >> >> So now,we can get two versions of source(for Eclipse 3.2 and for Eclipse >> 3.3+) from repository, >> and the sources are shared each. >> If you want to get the source for Eclipse 3.3,check out >> org.ginkgo.gcov, >> org.ginkgo.gcov.ui.e33, >> org.ginkgo.gcov.feature.e33, and >> org.ginkgo.gcov.update.e33, >> from /branches/for_merge. >> >> But the repository become very confusing,you know. >> And it seems hard to maintain. >> >> So I want smart idea to resolve it. >> Do you have any idea? >> >> Thank You >> Best Regards >> >> 2008/12/2 Frederic Belouin >> >> Hello yuuki, (Is it your name?) >>> >>> I don't know when I can help you for merge. >>> But I should be happy If I found time to do this. >>> >>> What is the procedure to do this stuff? >>> >>> >>> I also see that you've got several source code branches; >>> what branch should I use? >>> >>> what is the difference between org.ginkgo.gcov.ui.e32 and >>> org.ginkgo.gcov.ui.e33? >>> >>> Thank You >>> >>> Best Regards >>> >>> Frederic Belouin >>> >>> >>> 2008/12/1 yuuki arisawa >>> >>> >>>> Hello >>>> >>>> Thank you for sending a patch! >>>> I'm sorry for late reply... >>>> >>>> Your modification seem to be very nice! >>>> especially in the third feature. >>>> > - Add Global coverage status in Coverage Navigator (it shows a >>>> global >>>> > coverage status + a coverage for each directories) >>>> That is the one of the big feature I want to use: ) >>>> >>>> I want to review your patch and merge it to main branch. >>>> But I am in busy now,so it may be fast to merge it yourself. >>>> >>>> And your following suggestions are interesting. >>>> >>>> In a Project with a lot of files, coverage calculation can takes a lot >>>>> of time >>>>> >>>> I think the reason why it takes a lot of time is gcov execution time. >>>> So, it may be effective that not parsing *.gcov files but parsing *.gcno >>>> and *.gcda files directory. >>>> >>>> - Add a stop target in the project; because eclipse cannot be used >>>>> until gcov builder is finished. >>>>> >>>> You are right,that should be background task. >>>> >>>> - The Builder file search is too slow, an other method should be used. >>>> >>>> It may be solved if *.gcno or *.gcda file include their source file's >>>> path. >>>> >>>> >>>>> - Possibility to use an external tools (for me it's an external make >>>>> target) that will execute gcov >>>>> >>>> Creating folder that linking to folder in the file system may help you. >>>> >>>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html >>>> >>>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html >>>> >>>> If I've time I should be happy to help you on development of the >>>>> plug-in, but your source code comments cannot be read by a French guy like >>>>> me :-) >>>>> >>>> Is it possible for you to translate source code comments in english? >>>>> >>>> I apologize to you to write comments in Japanese. >>>> So I promise you to translate these comments in English as soon as >>>> possible. >>>> >>>> Best Regards >>>> >>>> 2008/11/25 Frederic Belouin >>>> >>>> Hello, >>>>> >>>>> I have modify your GCov for eclipse plugin >>>>> >>>>> Based on 0.22 tagged version I have: >>>>> - translate Builder Labels in English (thank to an automatic >>>>> translator). >>>>> - Correct a bug in Navigator builder: Now Navigator view show the >>>>> coverage status >>>>> - Add Global coverage status in Coverage Navigator (it shows a global >>>>> coverage status + a coverage for each directories) >>>>> - Add Clean-up of Coverage Navigator when project is cleaned >>>>> >>>>> >>>>> I think there are some problems with the design of this coverage tool: >>>>> - Coverage builder and the coverage result extraction should be >>>>> separate using >>>>> >>>>> - Builder for gcov execution >>>>> >>>>> >>>>> - Error parser to retrieve result of coverage >>>>> >>>>> In a Project with a lot of files, coverage calculation can takes a lot >>>>> of time (with > 200 files it takes several hours) >>>>> >>>>> - Add a stop target in the project; because eclipse cannot be used >>>>> until gcov builder is finished. >>>>> >>>>> - The Builder file search is too slow, an other method should be used. >>>>> >>>>> - Possibility to use an external tools (for me it's an external make >>>>> target) that will execute gcov >>>>> >>>>> I like what you have done with this coverage tools. >>>>> >>>>> If I've time I should be happy to help you on development of the >>>>> plug-in, but your source code comments cannot be read by a French guy like >>>>> me :-) >>>>> Is it possible for you to translate source code comments in english? >>>>> >>>>> Best Regards >>>>> >>>>> Fr?d?ric Belouin >>>>> >>>> >>>> >>>> >>>> -- >>>> Yuuki Arisawa >>>> yuuki.ari ?? gmail.com >>>> >>>> >>> >> >> >> -- >> Yuuki Arisawa >> yuuki.ari ?? gmail.com >> >> > -- Yuuki Arisawa yuuki.ari ?? gmail.com -------------- next part -------------- HTML????????????????????????????... URL: http://lists.sourceforge.jp/mailman/archives/ginkgo-dev/attachments/20081216/47b0d176/attachment.htm From yuuki.ari at gmail.com Thu Dec 18 23:34:30 2008 From: yuuki.ari at gmail.com (yuuki arisawa) Date: Thu, 18 Dec 2008 23:34:30 +0900 Subject: [Ginkgo-dev] =?GB2312?B?UmU6IKXqpd2luKXIpeqkzpiLs8mky6TEpKSkxqTOpLTP4NWEIEZ3ZDogTmV3?= =?GB2312?B?IGZlYXR1cmVzIGluIEdDb3YgZm9yIEVjbGlwc2U=?= In-Reply-To: <3a6ca8920812040723k26b3b5e9pea59ea5c8cd4121e@mail.gmail.com> References: <3a6ca8920812040723k26b3b5e9pea59ea5c8cd4121e@mail.gmail.com> Message-ID: <3a6ca8920812180634p3771985ajd153c337e956aa68@mail.gmail.com> Muranaka????: ???????????? gcov plugin ???????????? ???????????????????????????????? ???`????????????????????git?????????????? ???????A?????????`???????????????????????????????? ???`?????????????????`???????????????????????????????????? ?????????????????????????U???????????????? git???????????????????????}?????????????????????? ???????????????????????B?j???????????? ???????????????????????? 2008/12/5 yuuki arisawa > > Muranaka?????? > > ???????????? > gcov plugin ???????????? > > ???????????????????????????????? > > ???}???????????? > ???????`???`?????????????????????????????????????????????????????????????????????????? > ?????z?????????????????????? > > ???????????`?????????H???????????????????????????????????????? > ???????????????`???????????????? > > ?????????_?????????????????`?????????? > ?????????????????????????????????I???????????????? > > ?Y?????????? > /branches/for_merge > ???????????????????????????? > ???????????????????????}???????????????????????????? > > ?????????????? > Eclipse?????`???????????????????`???? > ?e???????????????????x????org.ginkgo.gcov.ui.e33,org.ginkgo.gcov.ui.e32?? > ??????????????(org.ginkgo.gcov)???????????????????????????? > > ???????????????????}?????????????????????????????????????? > ?????`?????`?????????????????`???????????}???????????????? > ?????_?k???????????????????????????????????????????? > > ?????????????????}???????? > ??????????????(org.ginkgo.gcov)?????????I???????????????????????????????? > ?`?????????????????`???????????????????????????????????????????????????? > > ??????????????????svn:external???????????????????????????????????}???????????Q?????????? > > ?????????????????????????????e???????????????????? > ?????????`???????H?????????????????????????????????????????????????????????????? > ???????????????????????????????}?????????????????? > > ????????????????????subversion????git???????\???Q???????????????????????????? > ?????????????? > > ????????subversion???????????\???????????????????????????? > > ?L???????????????????????????? > ???????????????????????????? > > ---------- Forwarded message ---------- > ??????: Frederic Belouin > Date: 2008/12/4 > Subject: Re: New features in GCov for Eclipse > To: yuuki arisawa > Cc: ginkgo-dev ?? lists.sourceforge.jp > > > Hello yuuki, > > I'm not very familiar with SVN. > I propose to use eclipse based work areas: > > /branches/eclipse3.2.x/ > /branches/eclipse3.2.x/org.ginkgo.gcov > /branches/eclipse3.2.x/org.ginkgo.gcov.ui > /branches/eclipse3.2.x/org.ginkgo.gcov.feature > /branches/eclipse3.2.x/org.ginkgo.gcov.update > > /branches/eclipse3.3/ > /branches/eclipse3.3.x/org.ginkgo.gcov > /branches/eclipse3.3.x/org.ginkgo.gcov.ui > /branches/eclipse3.3.x/org.ginkgo.gcov.feature > /branches/eclipse3.3.x/org.ginkgo.gcov.update > > > /branches/eclipse3.4/ > /branches/eclipse3.4.x/org.ginkgo.gcov > /branches/eclipse3.4.x/org.ginkgo.gcov.ui > /branches/eclipse3.4.x/org.ginkgo.gcov.feature > /branches/eclipse3.4.x/org.ginkgo.gcov.update > > ... > > /trunk/release/ (a link to the latest release) > > About ginko version, you should use: > > for beta release: > 0.3.2.betaY -->for eclipse 3.2 > 0.3.3.betaY -->for eclipse 3.3 > 0.3.4.betaY -->for eclipse 3.4 > > for release candidate: > 0.3.2.rcY -->for eclipse 3.2 > 0.3.3.rcY -->for eclipse 3.3 > 0.3.4.rcY -->for eclipse 3.4 > > for release: > 3.2.Y -->for eclipse 3.2 > 3.3.Y -->for eclipse 3.3 > 3.4.Y -->for eclipse 3.4 > > Advantage, you can easily merge modification on several plug-in versions > You don't need to create directories for minor versions > > > What do you think about this? > > Best Regards > Frederic Belouin > > > 2008/12/3 yuuki arisawa >> >> Hello Frederic. >> This is yuuki. >> >> I'm happy to hear that you are willing to help me. >> Of course it will be all right to help me whenever you have enough time. >> >> I try to answer your questions. >> >>> I also see that you've got several source code branches; >>> what branch should I use? >> >> There is three branches in the repository. >> >> The first and oldest branch is /trunk. >> This was the branch I used to developped. >> Version 0.2.2 is based on this branch. >> The differences between 0.2.2(rev.68) and trunk(rev.90) are coverage history view and bug fix. >> >> The second is /branches/monamour. >> This is the branch where MURANAKA ported this plug-in to Eclipse 3.2??Callisto??. >> It's based on trunk(rev.26). >> >> The last is /branches/for_merge. >> This is the branch where I tried to integrate /trunk and /branches/monamour. >> I separate the source which depend on eclipse version >> (org.ginkgo.gcov.ui.e33 and org.ginkgo.gcov.ui.e32) >> and the source which independ from eclipse version >> (org.ginkgo.gcov). >> >> So now,we can get two versions of source(for Eclipse 3.2 and for Eclipse 3.3+) from repository, >> and the sources are shared each. >> If you want to get the source for Eclipse 3.3,check out >> org.ginkgo.gcov, >> org.ginkgo.gcov.ui.e33, >> org.ginkgo.gcov.feature.e33, and >> org.ginkgo.gcov.update.e33, >> from /branches/for_merge. >> >> But the repository become very confusing,you know. >> And it seems hard to maintain. >> >> So I want smart idea to resolve it. >> Do you have any idea? >> >> Thank You >> Best Regards >> >> 2008/12/2 Frederic Belouin >>> >>> Hello yuuki, (Is it your name?) >>> >>> I don't know when I can help you for merge. >>> But I should be happy If I found time to do this. >>> >>> What is the procedure to do this stuff? >>> >>> >>> I also see that you've got several source code branches; >>> what branch should I use? >>> >>> what is the difference between org.ginkgo.gcov.ui.e32 and org.ginkgo.gcov.ui.e33? >>> >>> Thank You >>> >>> Best Regards >>> >>> Frederic Belouin >>> >>> >>> 2008/12/1 yuuki arisawa >>>> >>>> Hello >>>> >>>> Thank you for sending a patch! >>>> I'm sorry for late reply... >>>> >>>> Your modification seem to be very nice! >>>> especially in the third feature. >>>> > - Add Global coverage status in Coverage Navigator (it shows a global >>>> > coverage status + a coverage for each directories) >>>> That is the one of the big feature I want to use: ) >>>> >>>> I want to review your patch and merge it to main branch. >>>> But I am in busy now,so it may be fast to merge it yourself. >>>> >>>> And your following suggestions are interesting. >>>> >>>>> In a Project with a lot of files, coverage calculation can takes a lot of time >>>> >>>> I think the reason why it takes a lot of time is gcov execution time. >>>> So, it may be effective that not parsing *.gcov files but parsing *.gcno and *.gcda files directory. >>>> >>>>> - Add a stop target in the project; because eclipse cannot be used until gcov builder is finished. >>>> >>>> You are right,that should be background task. >>>> >>>>> - The Builder file search is too slow, an other method should be used. >>>> >>>> It may be solved if *.gcno or *.gcda file include their source file's path. >>>> >>>>> >>>>> - Possibility to use an external tools (for me it's an external make target) that will execute gcov >>>> >>>> Creating folder that linking to folder in the file system may help you. >>>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-August/000013.html >>>> http://lists.sourceforge.jp/mailman/archives/ginkgo-users/2008-October/000014.html >>>> >>>>> If I've time I should be happy to help you on development of the plug-in, but your source code comments cannot be read by a French guy like me :-) >>>>> >>>>> Is it possible for you to translate source code comments in english? >>>> >>>> I apologize to you to write comments in Japanese. >>>> So I promise you to translate these comments in English as soon as possible. >>>> >>>> Best Regards >>>> >>>> 2008/11/25 Frederic Belouin >>>>> >>>>> Hello, >>>>> >>>>> I have modify your GCov for eclipse plugin >>>>> >>>>> Based on 0.22 tagged version I have: >>>>> - translate Builder Labels in English (thank to an automatic translator). >>>>> - Correct a bug in Navigator builder: Now Navigator view show the coverage status >>>>> - Add Global coverage status in Coverage Navigator (it shows a global coverage status + a coverage for each directories) >>>>> - Add Clean-up of Coverage Navigator when project is cleaned >>>>> >>>>> >>>>> I think there are some problems with the design of this coverage tool: >>>>> - Coverage builder and the coverage result extraction should be separate using >>>>> >>>>> Builder for gcov execution >>>>> >>>>> Error parser to retrieve result of coverage >>>>> >>>>> In a Project with a lot of files, coverage calculation can takes a lot of time (with > 200 files it takes several hours) >>>>> >>>>> - Add a stop target in the project; because eclipse cannot be used until gcov builder is finished. >>>>> >>>>> - The Builder file search is too slow, an other method should be used. >>>>> >>>>> - Possibility to use an external tools (for me it's an external make target) that will execute gcov >>>>> >>>>> I like what you have done with this coverage tools. >>>>> >>>>> If I've time I should be happy to help you on development of the plug-in, but your source code comments cannot be read by a French guy like me :-) >>>>> Is it possible for you to translate source code comments in english? >>>>> >>>>> Best Regards >>>>> >>>>> Fr??d??ric Belouin >>>> >>>> >>>> >>>> -- >>>> Yuuki Arisawa >>>> yuuki.ari ?? gmail.com >>>> >>> >> >> >> >> -- >> Yuuki Arisawa >> yuuki.ari ?? gmail.com >> > > > > > -- > Yuuki Arisawa > yuuki.ari ?? gmail.com > -- Yuuki Arisawa yuuki.ari ?? gmail.com