Menu
▾
▴
opencxx-users
|
From: Grzegorz J. <ja...@ac...> - 2004-08-30 13:09:39
|
Hi, OpenC++ 2.8 is out. This release encompasses a number of changes that are being introduced in a broader effort to refactor OpenC++ so that parts of it are reusable as independent libraries. Major changes in this release include: * separation of lexer&parser into self-contained library, * move out of gc, which from now on is an external dependency, not a part of OpenC++, * refactored and simplified test harness * prototype of script based driver (occ2) which is meant to replace platform-sensitive logic in occ executable. As usual, several bugs were fixed too. 2.8 was tested on Debian and RedHat (CF), it is also very close to working out-of-the-box on Cygwin, and reasonably close on XP. This release would not be possible without large and small contributions by many volunteers, in particular: Yann Dirson Dmitri Grigorenko Brian Kahne Jean-Sebastien Mouret Asen Kovachev Marc Ordinas i Llopis Horacio Pena Ferdinand Prantl Shishir Ramam Stefan Seefeld Gilles Seguin Alexandre Tolmos (Hope I did not miss anybody; if this is the case, offended are encouraged to challenge me for a duel immediately.) Big thanks to all contributors! HUGE THANKS go to Stefan Seefeld, a veteran OpenC++ user and reuser (see breathtaking project Synopsis), who contributed a lot of ideas, design and code to this release. Release 2.8 is definitely a step toward modularisation of OpenC++. This promises benefits, but also poses new challenges. Personally, I look at the OpenC++ project not only as a useful tool and library, but also as a perfect spot to get in touch with compiler technology and honest workout in OO-design and software engineering. I hope that the new challenges will continue to attract contributors and that soon we can arrive at fully functional, multiplatform, highly reusable OpenC++ Frontend Library. Would that qualify for '3.0' ? ;-) Best regards Grzegorz |
|
From: <se...@in...> - 2004-08-30 13:58:06
|
On Mon, 2004-08-30 at 09:04, Grzegorz Jakacki wrote:
> Hi,
> HUGE THANKS go to Stefan Seefeld, a veteran OpenC++ user and reuser (see
> breathtaking project Synopsis), who contributed a lot of ideas, design
> and code to this release.
What do we do with synopsis,
- must we try to merge,
1) Stephan, do you have suggestions.
2) Synopsis seams to have reformat source files,
do we have a standard for preferred format.
Stephan, have you used an utility(indent).
3) Header files have changed from .h to .hh, must we do it.
> Release 2.8 is definitely a step toward modularization of OpenC++.
> This promises benefits, but also poses new challenges.
> Personally, I look at the OpenC++ project not only as a useful tool
> and library, but also as a perfect spot to get in touch with
> compiler technology and honest workout in OO-design and software
> engineering. I hope that the new challenges will continue to attract
> contributors and that soon we can arrive at fully functional,
> multiplatform,
Can we create a branch( branch-281).
- do we merge first, and branch from there.
Dmitriy can you help with with the Cygwin compatibility.
> highly reusable OpenC++ Frontend Library.
> Would that qualify for '3.0' ? ;-)
Thanks for your great work Grzegorz.
|
|
From: Grigorenko D. <pos...@na...> - 2004-08-30 20:38:09
|
Hello > Dmitriy can you help with with the Cygwin compatibility. With wat? With Synopsis? I am not sure. In any case I can try to compile it and post results. |
|
From: Stefan S. <se...@sy...> - 2004-08-31 00:47:31
|
Gilles J. Seguin wrote: > What do we do with synopsis, > - must we try to merge, > 1) Stephan, do you have suggestions. not at this point. I'm still (as you may see if you follow my mails ;-) learning my way through opencxx, cleaning up and refactoring the code in 'my branch'. We should, however, discuss to find out whether we can agree on common goals, and if so, on the means to get there. If that is done, we may think about whether it is worth to merge, and how. Let's do one step at a time. I believe the first step should be an assessment of the current functionality. This involves a lot of reverse-engineering (for me at least, as my understanding of opencxx is still limitted), as well as the setup of lots of applets to demonstrates how opencxx is working (unit tests are the best means for that). I'v been doing this with synopsis over the last couple of weeks, and I hope I can help you do the same with opencxx, so we can compare. Does this make sense ? Regards, Stefan PS: I'll write down some thoughts on the design in another mail... |
|
From: <se...@in...> - 2004-08-31 14:50:42
|
On Mon, 2004-08-30 at 20:44, Stefan Seefeld wrote: > Gilles J. Seguin wrote: > > > What do we do with synopsis, > > - must we try to merge, > > 1) Stephan, do you have suggestions. > > not at this point. I'm still (as you may see if you follow my mails ;-) > learning my way through opencxx, cleaning up and refactoring the code > in 'my branch'. About 'my branch', I am puzzle. Does this branch is in opencxx or synopsis. If in opencxx, I was under the impression that modification in CVS where sending email to ope...@li.... What is the name of the branch. I may not be aware of a lot of work you have been doing. I am tracking through syn...@fr... > We should, however, discuss to find out whether we can agree on common > goals, and if so, on the means to get there. If that is done, we may > think about whether it is worth to merge, and how. > Let's do one step at a time. One step that I have try to do is documenting the grammar. My goal was to derive tests that verify that this grammar correspond to what the program is doing. And also validate that changed codes do not produce unforeseen effects. My suggestion will be to used grammar with the PCCTS style. What I try to get from the PCCTS style grammar is, the semantic|syntactic predicates. Semantic predicate is a parsing decision, on choice of alternative rules based, from information not available to a pure LL(k) parser. For example, bool isTypeSpecifier() is the implementation of a syntactic predicate. a:= (A)* B a:= (A)* C is now a:= ( (A)* B )? (A)* B a:= (A)* C more information from "Language Translation Using PCCTS and C++" see <http://www.antlr.org/book.pcctsbk.pdf> page 28 Can you qualify relevance of this grammar (important, urgent, not useful, later) > I believe the first step should be an assessment of the current > functionality. Agree. Previous comment was about documenting internal. > This involves a lot of reverse-engineering (for me at least, > as my understanding of opencxx is still limitted), > as well as the setup of lots of applets to demonstrates how opencxx > is working (unit tests are the best means for that). > I'v been doing this with synopsis over the last couple of weeks, and > I hope I can help you do the same with opencxx, so we can compare. It is a must on my list. It is important and urgent. That is, duplicate the qmtest from synopsis, Stephan is this what you are referring to, confirm. > Does this make sense ? A lot of sense. |
|
From: Stefan S. <se...@sy...> - 2004-09-01 00:16:28
|
Gilles J. Seguin wrote: > About 'my branch', I am puzzle. > Does this branch is in opencxx or synopsis. > If in opencxx, I was under the impression that modification in CVS > where sending email to ope...@li.... > What is the name of the branch. I may not be aware of a lot of > work you have been doing. > I am tracking through syn...@fr... yeah, I'm talking about synopsis. Sorry if that wasn't clear. And again, half of my checkins don't show up on the synopsis-changes list as the diffs are so big that it wouldn't make sense to mail them. I'll patch the commit-email.pl script some day to skip the diffs if they exceed some size... >>We should, however, discuss to find out whether we can agree on common >>goals, and if so, on the means to get there. If that is done, we may >>think about whether it is worth to merge, and how. >>Let's do one step at a time. > > > One step that I have try to do is documenting the grammar. > My goal was to derive tests that verify that this grammar correspond > to what the program is doing. And also validate that changed codes > do not produce unforeseen effects. right, that's what regression tests are all about, aren't they ? > My suggestion will be to used grammar with the PCCTS style. > What I try to get from the PCCTS style grammar is, > the semantic|syntactic predicates. > > Semantic predicate is a parsing decision, on choice of alternative rules > based, from information not available to a pure LL(k) parser. > For example, bool isTypeSpecifier() is the implementation of a > syntactic predicate. > a:= (A)* B > a:= (A)* C > is now > a:= ( (A)* B )? (A)* B > a:= (A)* C > more information from "Language Translation Using PCCTS and C++" > see <http://www.antlr.org/book.pcctsbk.pdf> page 28 > > Can you qualify relevance of this grammar > (important, urgent, not useful, later) yes, any test with a somewhat good coverage of potential input will help us. If you can come up with either some test applets or simply a set of input files that feature all the important language constructs we should test the parser against, I'll help us a lot. >>This involves a lot of reverse-engineering (for me at least, >>as my understanding of opencxx is still limitted), >>as well as the setup of lots of applets to demonstrates how opencxx >>is working (unit tests are the best means for that). >>I'v been doing this with synopsis over the last couple of weeks, and >>I hope I can help you do the same with opencxx, so we can compare. > > > It is a must on my list. It is important and urgent. > That is, duplicate the qmtest from synopsis, > Stephan is this what you are referring to, confirm. yep, it is. In fact, with some luck I could check in some basic test harness into opencxx mainline still tonight, within which we then can add test applets as well as input files (as the ones you are proposing above). Regards, Stefan |
|
From: Grzegorz J. <ja...@ac...> - 2004-09-01 14:13:05
|
Stefan Seefeld wrote: >> It is a must on my list. It is important and urgent. >> That is, duplicate the qmtest from synopsis, Is there any chance that we do not duplicate, just share the common part? >> Stephan is this what you are referring to, confirm. > > > yep, it is. In fact, with some luck I could check in some basic test > harness into opencxx mainline still tonight, within which we then can > add test applets as well as input files (as the ones you are proposing > above). What modules do your tests exercise? |
|
From: Stefan S. <se...@sy...> - 2004-09-02 00:26:47
|
Grzegorz Jakacki wrote: > > > Stefan Seefeld wrote: > >>> It is a must on my list. It is important and urgent. >>> That is, duplicate the qmtest from synopsis, > > > Is there any chance that we do not duplicate, just share the common part? for the tests I'd actually want to duplicate. (No worries, setting up qmtest is quite simple, once you'v done it once or twice :-) The reason is that we really should assess the status quo so we can measure regressions. In the long run these tests will be obsolete, but on the road we'll very much appreciate such guidance. > What modules do your tests exercise? I'v three test applets right now: one for the Lexer, one for the parser (without translation), and one for encodings. As synopsis doesn't use the translation step I'v not yet set up parser with translation as another test applet. Please note that I'm talking about the testing framework. I still need to fill it with real tests, i.e. I should provide input files that cover all possible syntax. I thus hope that Gilles will help us to do that systematically. Regards, Stefan |
|
From: <se...@in...> - 2004-09-01 21:20:51
|
On Tue, 2004-08-31 at 20:13, Stefan Seefeld wrote: > > One step that I have try to do is documenting the grammar. > > My goal was to derive tests that verify that this grammar correspond > > to what the program is doing. And also validate that changed codes > > do not produce unforeseen effects. > > right, that's what regression tests are all about, aren't they ? > > > My suggestion will be to used grammar with the PCCTS style. > > What I try to get from the PCCTS style grammar is, > > the semantic|syntactic predicates. > > [...] > > Can you qualify relevance of this grammar > > (important, urgent, not useful, later) > > yes, any test with a somewhat good coverage of potential input will help > us. If you can come up with either some test applets or simply a set of > input files that feature all the important language constructs Those language constructs are the one of OpenC++, right. Do you have an idea/suggestion of the structure of the test directory. For example, here following ISO/IEC 14882 test suite +- expression +- statements +- declarations +- declarators +- classes +- derived classes +- member access control +- special member control +- overloading +- templates | +- template parameter | +- template arguments +- exception handling > we should test the parser against, I'll help us a lot. |
|
From: Stefan S. <se...@sy...> - 2004-09-02 00:35:35
|
Gilles J. Seguin wrote: > Those language constructs are the one of OpenC++, right. > Do you have an idea/suggestion of the structure of the test directory. I'd keep it simple. A valid, self-contained source file will always contain a mix of these types (statements and expressions). I'd just use meaningful filenames that tell people what the focus of the test is. Let's say, some files/tests for simple variable declarations with builtin types, some for struct / class declarations, some to test inheritance (testing 'virtual', 'public', 'private', MI, etc., etc.), some to test the various template types. You get the idea... Regards, Stefan |
|
From: Stefan S. <se...@sy...> - 2004-09-11 00:29:22
|
Hi Gilles, Gilles J. Seguin wrote: > Those language constructs are the one of OpenC++, right. > Do you have an idea/suggestion of the structure of the test directory. > For example, > here following ISO/IEC 14882 [...] did you have a look into these ? I'd be interested in putting them into synopsis' testing framework and, if it's ok with everybody here into opencxx, too. Grzegorz, what about my other mail ? Do you agree to make the change I propose, i.e. let 'occ' display the translated ptree if no '-p' option is given ? Gilles, did you have a look into the qmtest harness I put into synopsis ? What do you think about it ? Should we put a copy of it (the part that concerns opencxx) into the opencxx repository ? Regards, Stefan |
|
From: Grzegorz J. <ja...@ac...> - 2004-09-11 17:01:56
|
Stefan Seefeld wrote:
> Hi Gilles,
>
> Gilles J. Seguin wrote:
>
>> Those language constructs are the one of OpenC++, right.
>> Do you have an idea/suggestion of the structure of the test directory.
>> For example,
>> here following ISO/IEC 14882
If I can comment on this: I think that directory layout is not that much
important. What is important is to have most cases covered by tests, and
for that purpose your list of features is a perfect reference. However
if the tests go into one directory or into several ones, it is much up
to the implementor (however personally I always try to restrain myself
from overengineering).
> [...]
>
> did you have a look into these ? I'd be interested in putting them
> into synopsis' testing framework and, if it's ok with everybody here
> into opencxx, too.
Ideally we could set up one common repo for the core part of opencxx
(nicknamed "OpenC++ Core) to be used by both OpenC++ and Synopsis.
For the information of everybody: Stefan and myself are discussing now
how we can join efforts of OpenC++ and Synopsis projects to advance the
functionality of the code that is shared by both projects.
> Grzegorz, what about my other mail ?
> Do you agree to make the change I propose, i.e. let 'occ' display the translated
> ptree if no '-p' option is given ?
Sorry for the delay.
First, occ already has '-s' option. I assume the output you implemented
is better suited for e.g. testing. If so, please go ahead, just put it
under an option, preferably a long one ('--...'), that way we minimize
chances to accidentally hit some "well-known" one-letter option.
BR
Grzegorz
|
|
From: Stefan S. <se...@sy...> - 2004-09-11 17:11:57
|
Grzegorz Jakacki wrote:
> Ideally we could set up one common repo for the core part of opencxx
> (nicknamed "OpenC++ Core) to be used by both OpenC++ and Synopsis.
ideally, yes. But no matter what we end up doing, I strongly believe
the opencxx code as it exists today should get this added, too, so
we can use it as a reference. Whenever we are unsure whether the
results we are seing elsewhere are correct, we can at least check
with the old occ tests whether it's a regression or whether it has
always been there.
>> Grzegorz, what about my other mail ? Do you agree to make the change I
>> propose, i.e. let 'occ' display the translated
>> ptree if no '-p' option is given ?
>
>
> Sorry for the delay.
>
> First, occ already has '-s' option. I assume the output you implemented
> is better suited for e.g. testing. If so, please go ahead, just put it
> under an option, preferably a long one ('--...'), that way we minimize
> chances to accidentally hit some "well-known" one-letter option.
yes, '-s' is already there. My proposal is to change the semantics such
that it will behave as it always did when '-p' is specified, and else
display the ptree after the translation instead of before.
I honestly strongly doubt anybody would ever notice, as '-s' seems to
me to be a debugging / testing / learning tool only.
The change I'd like to make is thus trivial and involves only three lines
of code that are moved down a bit :-)
Regards,
Stefan
|
|
From: Grzegorz J. <ja...@ac...> - 2004-09-11 17:20:45
|
Stefan Seefeld wrote:
[...]
>>> Grzegorz, what about my other mail ? Do you agree to make the change
>>> I propose, i.e. let 'occ' display the translated
>>> ptree if no '-p' option is given ?
>>
>>
>>
>> Sorry for the delay.
>>
>> First, occ already has '-s' option. I assume the output you
>> implemented is better suited for e.g. testing. If so, please go ahead,
>> just put it under an option, preferably a long one ('--...'), that way
>> we minimize chances to accidentally hit some "well-known" one-letter
>> option.
>
>
> yes, '-s' is already there. My proposal is to change the semantics such
> that it will behave as it always did when '-p' is specified, and else
> display the ptree after the translation instead of before.
Yes, that makes sense to me, pls. go ahead.
BR
Grzegorz
>
> I honestly strongly doubt anybody would ever notice, as '-s' seems to
> me to be a debugging / testing / learning tool only.
>
> The change I'd like to make is thus trivial and involves only three lines
> of code that are moved down a bit :-)
>
> Regards,
> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
|
|
From: Stefan S. <se...@sy...> - 2004-09-11 18:05:40
|
Grzegorz Jakacki wrote: >> yes, '-s' is already there. My proposal is to change the semantics such >> that it will behave as it always did when '-p' is specified, and else >> display the ptree after the translation instead of before. > > > Yes, that makes sense to me, pls. go ahead. ... >> I honestly strongly doubt anybody would ever notice, as '-s' seems to >> me to be a debugging / testing / learning tool only. > > >> >> The change I'd like to make is thus trivial and involves only three lines >> of code that are moved down a bit :-) ok, The change is checked in. I'v tried it out and I'm a bit surprized, as I expected to find the translation to modify the ptree in almost all cases, but a little test I ran didn't appear to do anything in the translation, i.e. the resulting ptree was identical to the original one. Why is that ? AFAIK translation includes the second stage of the parsing (i.e. resolving any ambiguities that only exist because to resolve them one needs a symbol lookup table which didn't exist in the first pass), and it also includes anything related to metaprogramming, i.e. metaclass tokens that were part of the original source, and are now expanded. Anyways, that's precisely one of the reasons I want to put this testing stuff in the original code: to be able to study occ systematically on a broad sample of existing input files. Regards, Stefan |
|
From: Grzegorz J. <ja...@ac...> - 2004-09-13 15:36:19
|
Stefan Seefeld wrote: > Grzegorz Jakacki wrote: > >>> yes, '-s' is already there. My proposal is to change the semantics such >>> that it will behave as it always did when '-p' is specified, and else >>> display the ptree after the translation instead of before. >> >> >> >> Yes, that makes sense to me, pls. go ahead. > > > ... > >>> I honestly strongly doubt anybody would ever notice, as '-s' seems to >>> me to be a debugging / testing / learning tool only. >> >> >> >>> >>> The change I'd like to make is thus trivial and involves only three >>> lines >>> of code that are moved down a bit :-) > > > ok, The change is checked in. > I'v tried it out and I'm a bit surprized, as I expected to find the > translation > to modify the ptree in almost all cases, but a little test I ran didn't > appear > to do anything in the translation, i.e. the resulting ptree was > identical to > the original one. Why is that ? Could you post an example? BR Grzegorz > AFAIK translation includes the second stage of the parsing (i.e. resolving > any ambiguities that only exist because to resolve them one needs a > symbol lookup > table which didn't exist in the first pass), and it also includes > anything related > to metaprogramming, i.e. metaclass tokens that were part of the original > source, > and are now expanded. > > Anyways, that's precisely one of the reasons I want to put this testing > stuff > in the original code: to be able to study occ systematically on a broad > sample > of existing input files. > > Regards, > Stefan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users |
|
From: <se...@in...> - 2004-09-07 18:59:11
|
On Tue, 2004-08-31 at 20:13, Stefan Seefeld wrote: > Gilles J. Seguin wrote: > > > About 'my branch', I am puzzle. > > Does this branch is in opencxx or synopsis. > > If in opencxx, I was under the impression that modification in CVS > > where sending email to ope...@li.... > > What is the name of the branch. I may not be aware of a lot of > > work you have been doing. > > I am tracking through syn...@fr... > > yeah, I'm talking about synopsis. Sorry if that wasn't clear. > And again, half of my checkins don't show up on the synopsis-changes > list as the diffs are so big that it wouldn't make sense to mail > them. I'll patch the commit-email.pl script some day to skip the > diffs if they exceed some size... Well, watcher that watch half the time is no fun. If we look at mailing list like <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/> choosing <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html> We have: - Modified files: - Added files: - Log message: - Patches: Here is the interesting modification. * * Do not send the patch, but a reference to the patch(es). * * They succeed to mystified my again. The loginfo file, contains the filter log_accum that they have replace with log_accum_bugzillafied, which I can not found the source/reference to it, sorry. That email was for saying, they have a mechanism for sending huge "reference" to patch. have fun, gilles |
|
From: Stefan S. <se...@sy...> - 2004-09-08 00:25:37
|
Gilles J. Seguin wrote: > Well, watcher that watch half the time is no fun. you can always look at http://synopsis.fresco.org/changelog.html to see all the checkins. The same data exist as an rss feed, too. > If we look at mailing list like > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/> > choosing > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html> > > We have: > - Modified files: > - Added files: > - Log message: > - Patches: > Here is the interesting modification. > * * Do not send the patch, but a reference to the patch(es). * * > > They succeed to mystified my again. well, if the data are too big to be included in the mail, just send a reference. That's another possibility: just mail an URL to the revision view via viewcvs. However, some people don't like that either because it's another indirection. It's always a trade-off... If you want to fix the commit-email.pl script to ommit diffs that are too big, here is the code: http://svn.collab.net/viewcvs/svn/trunk/tools/hook-scripts/commit-email.pl.in?rev=10787&view=auto Regards, Stefan |
|
From: Grzegorz J. <ja...@he...> - 2004-09-08 06:54:29
|
Hi Gilles & Stefan, You may want to reuse the solution that is in place at opencxx.sf.net, this is a Python script, it always sends links. Very easy to modify (but I am not sure what changes are required to hook it up to svn). You can find it in CVSROOT module of opencxx.sf.net BR Grzegorz On Tue, 7 Sep 2004, Stefan Seefeld wrote: > Gilles J. Seguin wrote: > > > Well, watcher that watch half the time is no fun. > > you can always look at http://synopsis.fresco.org/changelog.html > to see all the checkins. The same data exist as an rss feed, too. > > > If we look at mailing list like > > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/> > > choosing > > <http://gcc.gnu.org/ml/libstdc++-cvs/2004-q3/msg00576.html> > > > > We have: > > - Modified files: > > - Added files: > > - Log message: > > - Patches: > > Here is the interesting modification. > > * * Do not send the patch, but a reference to the patch(es). * * > > > > They succeed to mystified my again. > > well, if the data are too big to be included in the mail, just > send a reference. That's another possibility: just mail an URL > to the revision view via viewcvs. However, some people don't like > that either because it's another indirection. It's always a trade-off... > > If you want to fix the commit-email.pl script to ommit diffs > that are too big, here is the code: > http://svn.collab.net/viewcvs/svn/trunk/tools/hook-scripts/commit-email.pl.in?rev=10787&view=auto > > Regards, > Stefan > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users > > ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2004 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: Grzegorz J. <ja...@ac...> - 2004-09-01 14:00:50
|
Gilles J. Seguin wrote: > On Mon, 2004-08-30 at 20:44, Stefan Seefeld wrote: > >>Gilles J. Seguin wrote: >> >> >>>What do we do with synopsis, >>>- must we try to merge, >>> 1) Stephan, do you have suggestions. >> >>not at this point. I'm still (as you may see if you follow my mails ;-) >>learning my way through opencxx, cleaning up and refactoring the code >>in 'my branch'. > > > About 'my branch', I am puzzle. Let's agree on a common repo ASAP. Stefan, what are the benefits of Fresco? Can OpenC++ get space there? Do we need to move repo there, wouldn't you move your branch of OpenC++ to SF? BR Grzegorz > Does this branch is in opencxx or synopsis. > If in opencxx, I was under the impression that modification in CVS > where sending email to ope...@li.... > What is the name of the branch. I may not be aware of a lot of > work you have been doing. > I am tracking through syn...@fr... > > >>We should, however, discuss to find out whether we can agree on common >>goals, and if so, on the means to get there. If that is done, we may >>think about whether it is worth to merge, and how. >>Let's do one step at a time. > > > One step that I have try to do is documenting the grammar. > My goal was to derive tests that verify that this grammar correspond > to what the program is doing. And also validate that changed codes > do not produce unforeseen effects. > > My suggestion will be to used grammar with the PCCTS style. > What I try to get from the PCCTS style grammar is, > the semantic|syntactic predicates. > > Semantic predicate is a parsing decision, on choice of alternative rules > based, from information not available to a pure LL(k) parser. > For example, bool isTypeSpecifier() is the implementation of a > syntactic predicate. > a:= (A)* B > a:= (A)* C > is now > a:= ( (A)* B )? (A)* B > a:= (A)* C > more information from "Language Translation Using PCCTS and C++" > see <http://www.antlr.org/book.pcctsbk.pdf> page 28 > > Can you qualify relevance of this grammar > (important, urgent, not useful, later) > > >>I believe the first step should be an assessment of the current >>functionality. > > > Agree. Previous comment was about documenting internal. > > >>This involves a lot of reverse-engineering (for me at least, >>as my understanding of opencxx is still limitted), >>as well as the setup of lots of applets to demonstrates how opencxx >>is working (unit tests are the best means for that). >>I'v been doing this with synopsis over the last couple of weeks, and >>I hope I can help you do the same with opencxx, so we can compare. > > > It is a must on my list. It is important and urgent. > That is, duplicate the qmtest from synopsis, > Stephan is this what you are referring to, confirm. > > >>Does this make sense ? > > > A lot of sense. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Opencxx-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencxx-users |
|
From: Grzegorz J. <ja...@ac...> - 2004-09-16 11:55:07
|
Hi Yann! Yann Dirson wrote: > Thanks for your great work, Grzegorz ! Great things are still to come!... (OpenC++ Core Lib) > Unfortunately, we're no out of libtool woes... > > On current Debian unstable using g++ 3.3, the configure script shows a > couple of strange things: > > | checking dlfcn.h usability... yes > | checking dlfcn.h presence... no > | configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! > | configure: WARNING: dlfcn.h: proceeding with the preprocessor's result > | configure: WARNING: ## ------------------------------------ ## > | configure: WARNING: ## Report this to bug...@gn.... ## > | configure: WARNING: ## ------------------------------------ ## > | checking for dlfcn.h... no > [...] > | checking whether to use garbage collector... no > > and in the end, the shared library is named libocc.0 (note the missing .so). > > Let's start with the latter since I've met him already. Although I > don't remember the gory details, IIRC it comes from a version mismatch > between ltmain.sh and some other part used to produce the ./libtool > script. > > Sync'ing libtool files with the version on my system (1.5.6-2) using > libtoolize, and subsequently regenerating all auto* stuff solves the > problem for me. Incidentally, it seems to solve the first issue as > well: > > | checking dlfcn.h presence... no > | configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor! > | configure: WARNING: dlfcn.h: proceeding with the compiler's result > | checking for dlfcn.h... yes > > I'm not sure what we can do to fix the problem for good... The best we can do is to make 'bootstrap' fail for libtool earlier than 1.5.6-2 on Debian (I don't know how it works on other Linux distros). > Now for the gc issue. In configure.in the code seems to assume > $enable_gc is empty if no --*able-gc flag was passed. However, the > generated configure script starts by setting it to "no" if it was > empty. This seems to explain that the gc is never selected. Oouuuu.... > Adding > "enable_gc=yes" before AC_ARG_ENABLE fixes the problem. Cool, but this means gc test were fakes :-( > But now, or if I just force it to yes using --enable-gc I get: > > | checking whether to use garbage collector... yes > | checking whether -lgc provides GC_malloc... yes > | checking gc.h usability... no > | checking gc.h presence... no > | checking for gc.h... no > | configure: error: gc.h not found; set up paths or --disable-gc > > It is apparently not looking for <gc/gc.h>, which would have allowed > to find it. I think it should look for <gc.h>, not <gc/gc.h> (and it does, configure.in:188). Why do you think it should be <gc/gc.h> ??? > OTOH, it does not seem to be used, so this particular > test can possibly be dropped. I am not sure I understand. Do you mean that testing for <gc/gc_cpp.h> is enough? If this is really the case, I agree. > Any objections to these changes ? No. Could you apply? Thanks! Grzegorz |
|
From: Yann D. <yd...@us...> - 2004-09-16 20:13:12
|
On Thu, Sep 16, 2004 at 07:49:53PM +0800, Grzegorz Jakacki wrote:
> Hi Yann!
>
> Yann Dirson wrote:
> >Thanks for your great work, Grzegorz !
>
> Great things are still to come!... (OpenC++ Core Lib)
Yes, I've read about that :)
> >Adding
> >"enable_gc=yes" before AC_ARG_ENABLE fixes the problem.
>
> Cool, but this means gc test were fakes :-(
Is it a test you just copied from the gc package ?
> >But now, or if I just force it to yes using --enable-gc I get:
> >
> >| checking whether to use garbage collector... yes
> >| checking whether -lgc provides GC_malloc... yes
> >| checking gc.h usability... no
> >| checking gc.h presence... no
> >| checking for gc.h... no
> >| configure: error: gc.h not found; set up paths or --disable-gc
> >
> >It is apparently not looking for <gc/gc.h>, which would have allowed
> >to find it.
>
> I think it should look for <gc.h>, not <gc/gc.h> (and it does,
> configure.in:188). Why do you think it should be <gc/gc.h> ???
Because I have an /usr/include/gc/gc.h and /usr/include/gc/gc_cpp.h
but no /usr/include/gc.h, and the <gc/gc_cpp.h> test succeeds.
OTOH, we could test for <gc.h> only <gc/gc.h> does not exist - the
reverse might find an outdated gc.h on some (broken) boxes.
> >OTOH, it does not seem to be used, so this particular
> >test can possibly be dropped.
>
> I am not sure I understand. Do you mean that testing for <gc/gc_cpp.h>
> is enough? If this is really the case, I agree.
If the occ code does not #include it directly, I don't think we should
make assumptions about what gc_cpp.h needs - the failure I experienced
seems to demonstrate this :)
> >Any objections to these changes ?
>
> No. Could you apply?
Sure !
Best regards,
--
Yann Dirson <yd...@al...> |
Debian-related: <di...@de...> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
|
|
From: Grzegorz J. <ja...@ac...> - 2004-09-16 23:46:28
|
o Yann Dirson wrote: > On Thu, Sep 16, 2004 at 07:49:53PM +0800, Grzegorz Jakacki wrote: > >>Hi Yann! >> >>Yann Dirson wrote: >> >>>Thanks for your great work, Grzegorz ! >> >>Great things are still to come!... (OpenC++ Core Lib) > > > Yes, I've read about that :) > > > >>>Adding >>>"enable_gc=yes" before AC_ARG_ENABLE fixes the problem. >> >>Cool, but this means gc test were fakes :-( > > > Is it a test you just copied from the gc package ? I mean that I was running withoug gc, thinking I run run with it. >>>But now, or if I just force it to yes using --enable-gc I get: >>> >>>| checking whether to use garbage collector... yes >>>| checking whether -lgc provides GC_malloc... yes >>>| checking gc.h usability... no >>>| checking gc.h presence... no >>>| checking for gc.h... no >>>| configure: error: gc.h not found; set up paths or --disable-gc >>> >>>It is apparently not looking for <gc/gc.h>, which would have allowed >>>to find it. >> >>I think it should look for <gc.h>, not <gc/gc.h> (and it does, >>configure.in:188). Why do you think it should be <gc/gc.h> ??? > > > Because I have an /usr/include/gc/gc.h and /usr/include/gc/gc_cpp.h > but no /usr/include/gc.h, and the <gc/gc_cpp.h> test succeeds. > > OTOH, we could test for <gc.h> only <gc/gc.h> does not exist - the > reverse might find an outdated gc.h on some (broken) boxes. Yes. >>>OTOH, it does not seem to be used, so this particular >>>test can possibly be dropped. >> >>I am not sure I understand. Do you mean that testing for <gc/gc_cpp.h> >>is enough? If this is really the case, I agree. > > > If the occ code does not #include it directly, I don't think we should > make assumptions about what gc_cpp.h needs - the failure I experienced > seems to demonstrate this :) Sure. >>>Any objections to these changes ? >> >>No. Could you apply? > > > Sure ! Thanks. BR Grzegorz > > Best regards, |
|
From: Yann D. <yd...@us...> - 2004-09-17 19:54:48
|
On Fri, Sep 17, 2004 at 07:41:21AM +0800, Grzegorz Jakacki wrote:
> >>No. Could you apply?
> >
> >
> >Sure !
>
> Thanks.
Committed to trunk. Should I commit to the rel_2_8 branch as well ?
--
Yann Dirson <yd...@al...> |
Debian-related: <di...@de...> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
|
|
From: Grzegorz J. <ja...@ac...> - 2004-09-21 13:22:34
|
Yann Dirson wrote: > On Fri, Sep 17, 2004 at 07:41:21AM +0800, Grzegorz Jakacki wrote: > >>>>No. Could you apply? >>> >>> >>>Sure ! >> >>Thanks. > > > Committed to trunk. Should I commit to the rel_2_8 branch as well ? Yes, please. I think that would make sense to tag it as 2.8.1 and release again. What do you think? BR Grzegorz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X