Menu
▾
▴
opencxx-users
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(16) |
Nov
(14) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(14) |
Feb
(57) |
Mar
(72) |
Apr
(37) |
May
(21) |
Jun
(12) |
Jul
(16) |
Aug
(33) |
Sep
(24) |
Oct
|
Nov
(10) |
Dec
(8) |
| 2004 |
Jan
(6) |
Feb
(14) |
Mar
(47) |
Apr
(41) |
May
(16) |
Jun
(31) |
Jul
(78) |
Aug
(62) |
Sep
(99) |
Oct
(43) |
Nov
(35) |
Dec
(9) |
| 2005 |
Jan
(19) |
Feb
(22) |
Mar
(7) |
Apr
|
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
(9) |
Sep
(15) |
Oct
(23) |
Nov
(2) |
Dec
(20) |
| 2006 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
|
May
|
Jun
(8) |
Jul
(15) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(9) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Grzegorz J. <ja...@he...> - 2003-05-13 10:52:38
|
On Thu, 1 May 2003, Evan Carew wrote: > I just ran my brand spanking new occ with gdb and got the following: > > Program received signal SIGSEGV, Segmentation fault. > 0x0807c53b in GC_register_dynamic_libraries () Try adding 'handle SIGSEGV pass noprint' to your '~/.gdbinit'. Regards Grzegorz > > I recieved this while trying to debug why it wasn't running. It turns > out that there is some kind of code that gets executed prior to the > "main()" entry function, presumably, the GC_Register... function > mentioned above. Any ideas how to fix this? > > Evan Carew > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > 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) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: Carsten P. <ca...@cs...> - 2003-05-07 17:11:59
|
=2D----BEGIN PGP SIGNED MESSAGE----- > I do have '.' in my LD_LIBRARY_PATH. Also, it seems to be finding the =20 > file: > =20 > ./VerboseClass.so: undefined symbol: > __tiQ27Opencxx5Class > =20 > It appears that it finds the file just fine, but that it encounters and=20 > undefined symbol in the file. c++filt __tiQ27Opencxx5Class Opencxx::Class type_info node Could it be that you have something like -fno-rtti in your CXXFLAGS or=20 something like that? Or maybe you're suffering from the same problem as I do, that libltdl doesn= 't=20 notice that I'm using a GNU ld. Hence, I have to put=20 occ_LDFLAGS =3D -export-dynamic into opencxx/src/Makefile and relink occ. Without that, no symbols of occ a= re=20 exported and VerboseClass.so therefore can't access them. Cheers Carsten Pfeiffer =2D----BEGIN PGP SIGNATURE----- iQEVAwUBPrk+DaWgYMJuwmZtAQFP7Af/T05te486U4s7FjD7QVREgxalhezaNAxG Tr9rSUDhddwa7Z8fYusgKPkEySIsT5aJJeMp3dW4TT4FNWvGpXgB7zBbZRBzT3/p z2dGEYB0ON1iDd6JdfrhjnpduYwo52R1Dhmfmy9+RB1Jqb/R/fvCyspQLtphKHga LpT1PGcmKDfEB3yeOWStjZS9QnCyQulk4kJ0oGEmE4cbW70oNOMc6tI9Ad3jpUMe iS/y9V9Hb4VO5j4qACFRcvM83i3EuSFHQ+pgfBHbBrt/Pp0tf7Zkv9j/DfQAqoB1 RCExdOhWOTiv1c8Ewn7/WIWt3pqBDMzKcSuvEiXF/hKMnCBpD7T5iw=3D=3D =3DEzC0 =2D----END PGP SIGNATURE----- |
|
From: Carsten P. <ca...@cs...> - 2003-05-07 01:12:14
|
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 06 May 2003 23:58, you wrote:
> _Obj* __restrict__ __result = *__my_free_list;
>
> I guess it doesn't like __restrict__, which seems to be a gcc extension to
> support "restricted pointers" of C99.
FWIW, I just committed this fix:
diff -u -p -B -w -r1.7 token.cc
- --- token.cc 23 Apr 2003 13:18:09 -0000 1.7
+++ token.cc 7 May 2003 01:10:20 -0000
@@ -799,6 +799,7 @@ static struct rw_table {
{ "__extension__", token(EXTENSION) },
{ "__inline__", token(INLINE) },
{ "__restrict", token(Ignore) },
+ { "__restrict__", token(Ignore) },
{ "__signed", token(SIGNED) },
{ "__signed__", token(SIGNED) },
#endif
(and sorry for posting the other mail with the wrong from-address)
Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----
iQEVAwUBPrhdHqWgYMJuwmZtAQFP+gf8CB5lT7HEOjKKO4E+ojhnfe2WTlIg71S8
euT9CabI1mntbXsmhXUeapepE1VmYV7c4mr6Tz7p7X1vSiNrF8S/yVlVCDl8DWez
fZACGCBgLtm0lAjbEoWHtLwvIDvvNvvz8y3euiQPZhfA/ugQ3ZNe0HmGHGysNeUp
TJKFHjdTBEigzlNam5SLnjgNDJRFGz2wDpV8S4GoNIXZtXBCygt/UcKRTA9Tk8DU
JQO5Tx+qvr+rFZkTLI6IopXHkSNQEmKMPi5JecFJUR21Sp04dRZVFmK6segeRqEu
uATonYTceUnRWplLzZAqBB0bIa4kjFHlGc64jcbUSDIWQC4gLb4rJQ==
=k24k
-----END PGP SIGNATURE-----
|
|
From: Shigeru C. <ch...@is...> - 2003-05-06 17:24:03
|
Dear OpenC++ users:
This is a final message to the old mailing list. Please use the new
mailing list
ope...@li...
from now on. If you have not subscribed the new list yet, please visit
the web page below. After sending this email, I'll change the old list
so that it simply forwards all the messages to the new list.
Thank you for your subscription of the old OpenC++ mailing list!
- Chiba
From: Shigeru Chiba <ch...@is...>
Subject: Re: [opencxx] OpenC++ mailing list
Date: Mon, 28 Apr 2003 19:15:09 +0900 (JST)
>
> Dear OpenC++ users:
>
> Now anybody can register yourself to the OpenC++ mailing list on
> sourceforge.net. Please visit this registration page:
>
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
> I will close the old list on May 5th.
>
> Chiba
|
|
From: Evan C. <ca...@po...> - 2003-05-01 20:01:41
|
I just ran my brand spanking new occ with gdb and got the following: Program received signal SIGSEGV, Segmentation fault. 0x0807c53b in GC_register_dynamic_libraries () I recieved this while trying to debug why it wasn't running. It turns out that there is some kind of code that gets executed prior to the "main()" entry function, presumably, the GC_Register... function mentioned above. Any ideas how to fix this? Evan Carew |
|
From: Evan C. <ca...@po...> - 2003-05-01 19:38:03
|
I am attempting to use OpenC++ with Coldstore, another sourceforge project. The problem is that I can't get a compiled version of openC++ to work. My version simply segfaults on a munmap call early on in the program's initialization. <sigh>. I am using gcc 2.96 on RedHat 7.3 if anyone can help. Evan |
|
From: Evan C. <ca...@po...> - 2003-05-01 19:34:22
|
Anyone gotten opencxx to compile and run on RedHat 7.3 with gcc 2.96? The system seems to compile, but I get a segfault when I run it. Evan |
|
From: Shigeru C. <ch...@is...> - 2003-04-29 18:36:34
|
I forward this. Since Larry is not subscribing the old list, his submissions are rejcted till we switch to the new list on May 5th. - Chiba > Date: Mon, 28 Apr 2003 12:38:17 -0600 > From: Larry Evans <jca...@pr...> > To: op...@cs... > Subject: clarity of reference.pdf p.3 > > Reference.pdf on p.3 contains the phrase: > > The translation by the metaobjects is applied not only a > member call but also other kinds of code involved with the > C++ class system, such as data member access and class > declaration. > > This would be clearer to me if it read: > > The translation by the metaobjects can BE applied not only TO > a member call but also TO other kinds of code involved with the > C++ class system, such as data member access and class > declaration. |
|
From: Shigeru C. <ch...@is...> - 2003-04-28 10:51:56
|
Dear OpenC++ users: Now anybody can register yourself to the OpenC++ mailing list on sourceforge.net. Please visit this registration page: https://lists.sourceforge.net/lists/listinfo/opencxx-users I will close the old list on May 5th. Chiba |
|
From: Shigeru C. <ch...@is...> - 2003-04-26 18:17:08
|
I forward this message because the majordomo rejects it as a non-member submission. - Chiba > Date: Sat, 26 Apr 2003 12:58:42 -0600 > From: Larry Evans <> > To: op...@cs... > Subject: Re: [opencxx] Let's break OpenC++ up > > On 2003-04-23 06:12 Grzegorz Jakacki wrote: > > On Mon, 14 Apr 2003, James Michael DuPont wrote: > [snip] > > > > I do not think that there is the universal set of types of nodes, perhaps > > cons/nil is the only common denominator. It is very much domain dependent > > and the framewok should not fix it. Take a look at SLT, which defines just > > requirements on types (concepts) of containers. STL algorithms can be used > > with any types, not only the ones defined in STL (standard containers' > > iterators). For an example: imagine somebody prepared universal set of nodes > > for C++ before Chiba invented OpenC++. Now comes Chiba and wants to have > > some nodes which represent arbitrary chunks of text inserted into C++ parse > > tree. It is very unlikely, that the person who focused on inventing > > "universal" C++ parse tree predicted Chiba's requirement. We are in similar > > situation. > My cursory view of this thread suggests that maybe this: > > http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html > > would be useful since, quoting from the above, this method: > > allows new classes to be added without any need to change existing ones > > Another version, hopefully easier to understand, is at: > > http://groups.google.com/groups?selm=387CE74C.B161F6D6%40earthlink.net&output=gplain > > |
|
From: Grzegorz J. <ja...@he...> - 2003-04-26 06:22:27
|
On Sat, 26 Apr 2003, Shigeru Chiba wrote: > > Hi Larry, > > Date: Fri, 25 Apr 2003 12:23:53 -0600 > From: Larry Evans <jca...@pr...> > To: op...@cs... > Subject: why no compiler-compiler to gen occ? > > > After downloading 2.6.1 and looking at the source files, I noticed > > there's no use of any kind of compiler-compiler such as antlr or > > yacc. The source code in parse.h looks like it could be generated > > by antlr (since it's recursive decent); hence, I'm wondering why > > antlr or something like it wasn't used. In "Design&Evolution" Stroustrup admits that using YACC for Cfront implementation was a mistake and gave him lots of headaches. Regards Grzegorz > > The reason is simple. Yacc, LALR(1), cannot parse C++ programs > without awkward tricks of the lexical analyzer. ANTLR was not very > popular when OpenC++ was written in around 1995 (at least, I didn't > know it.) The final reason is that writing an LL(k) with-back-tracking > parser by hand is easy. At that time, I thought I should not have > wasted time for finding some nice compiler-compiler but started > writing a parser by hand. > > If I rewrite OpenC++ today, hmm.. I might use ANTLR. I don't know. > > Chiba > > ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: Shigeru C. <ch...@is...> - 2003-04-25 17:27:26
|
Hi Larry,
Date: Fri, 25 Apr 2003 12:23:53 -0600
From: Larry Evans <jca...@pr...>
To: op...@cs...
Subject: why no compiler-compiler to gen occ?
> After downloading 2.6.1 and looking at the source files, I noticed
> there's no use of any kind of compiler-compiler such as antlr or
> yacc. The source code in parse.h looks like it could be generated
> by antlr (since it's recursive decent); hence, I'm wondering why
> antlr or something like it wasn't used.
The reason is simple. Yacc, LALR(1), cannot parse C++ programs
without awkward tricks of the lexical analyzer. ANTLR was not very
popular when OpenC++ was written in around 1995 (at least, I didn't
know it.) The final reason is that writing an LL(k) with-back-tracking
parser by hand is easy. At that time, I thought I should not have
wasted time for finding some nice compiler-compiler but started
writing a parser by hand.
If I rewrite OpenC++ today, hmm.. I might use ANTLR. I don't know.
Chiba
|
|
From: Vladimir R. <va...@sk...> - 2003-04-24 19:21:53
|
On Wed, Apr 23, 2003 at 08:13:30PM +0800, Grzegorz Jakacki wrote:
> Vladimir,
>
> Thanks for your feedback. Detailed comments below:
>
> > 2. I found that new STL (coming with gcc v3.2.2) is little more
> > complex than `occ' expect, namely in parsing some template
> > typedefs. Some dumb workaround leads to infinite loop in type
> > analyzing stage (many parser-alike progs has same property :-)
>
> It seems to me that I have been fixing something similar in still
> experimental templates branch.
Very interesting!
I will upgrade to 2.6.1 soon and will see template branch
>
> > Currently i have a version which works fine (skipping some code,
> > so it is very dirty hack). It is possible to investigate it
> > (may be too late, if new version parses new STL fine).
> > So, possibly this topic is not actual now.
>
> What is your fix exactly?
This was hack, not a fix :-)
Any fix will be reported immediately, sure.
>
> > 3. I found that classwalker gives more attention for class/method
> > than non-OO code. So, automatic variables are not user-keyword
> > sensitive (if i understand it properly :-) Some additions make
> > it more care, and automatic variables are handling well.
>
> If you have any code that can extend existing functionality we can talk
> about incorporating it into occ.
First i hope to carry out handling code from general walker to user class
by standard for occ way, then i will able to send a patch for observation.
>
> > Currently we constructed first version of T++->(C++,TSS) converter using `occ'.
> > T++ is a `superfunctional' language for supercomputers, and has
> > seven additional keywords: tfun, tval, tptr, tout, twait, tdrop, tct.
> >
> > For instance, Fibonacci program looks like:
> >
> > #include <stdio.h>
> >
> > tfun int fib (int n) {
> > return n < 2 ? n : fib(n-1)+fib(n-2);
> > }
> >
> > tfun int main (int argc, char **argv) {
> > if (argc != 2) { printf("Usage: fib <n>\n"); return 1; }
> > int n = atoi(argv[1]);
> > printf("fib(%d) = %d\n", n, (int)fib(n));
> > return 0;
> > }
> >
> > Running on multicomputer, it will do all recursions in parallel.
>
> Wow, cool.
>
I see only one additional feature we for our current purposes:
We need user-defined keyword `tct` with parameters:
Someone can write:
tfun tct((stack(4096),prio(5))) f(int x) { ... }
it means that LWP for function f should have stack size = 4096 bytes
and macroscheduler priority = 5
Another case:
tval A a = new tval tct((extent(2048))) A;
Here we expect to allocate synchronized value with type A and 2048
bytes after it, accessible from all cluster nodes (i.e. inform
system about additional memory which should be transferred during
access)
Your can consider 'tct' (T-context info) like __attribute__ in gcc.
So it is not a new idea
And there is some objectives to support user keywords with parameters:
Any real language extension has dilemma: to put maximal information to
minimal set of new keywords. Parameterization can solve this problem:
we can introduce few very often used keywords, and reserve one with
many parameters for other cases.
occ supports keywords with parameters, it is great!!!
i hope it will work :-)
--
Best regards,
Vladimir
|
|
From: Shigeru C. <ch...@is...> - 2003-04-24 18:05:13
|
From: Grzegorz Jakacki <ja...@he...> Subject: Re: [opencxx] OpenC++ mailing list Date: Fri, 25 Apr 2003 00:59:59 +0800 (CST) > > Here is my idea: > > > > - Next monday April 21st, > 28th ??? 28th is correct although some have already subscribed the list. > > I make the mailing list on sourceforge > > subscribable by anybody. (Now, subscription is not allowed.) > > So you can start subscribing that mailing list. But you cannot > > directly post a message to the list. You have to post to the > > current list op...@cs.... > > > > Subscription is just one click on this page: > > > > https://lists.sourceforge.net/lists/listinfo/opencxx-users > > > > (Between April 21 and May 6th, you will receive duplicated messages > > from the two lists.) > > > > - Monday May 5th, you can start posting a message to the list on > > sourceforge. The old list stops distribution but it forwards > > a posted message to the list on sourceforge. > > > > - End of May, I close the old list. > > Could you set up auto-reply on the old address for some time (3 months?) > with a link to the new list? OK, I'll do that. I think we need more than one list administrator (currently, I'm the only one). Who can take that role? Chiba |
|
From: Grzegorz J. <ja...@he...> - 2003-04-24 17:27:39
|
Hi, On Thu, 24 Apr 2003, Shigeru Chiba wrote: > > Dear OpenC++ mailing list subscribers: > > As you may notice, this list is currently maintained in a weird way. > The posted messages are distributed by a mail server in Tokyo while > they are archived by sourceforge.net. This is why you receive some > annoying messages from sourceforge.net if you post a message. > > Since none seems to have objection to my last message, I would like > to close op...@cs... and ask you all to subscribe > ope...@li.... Although I asked long time ago > the sourceforge admin to register all the current subscribers, > they seem very busy. So I think that all of us subscribe the list > by ourselves would be good. It is also good since some subscribers > may want not to receive messages any more. Totally agreed. Two comments however: > > Here is my idea: > > - Next monday April 21st, 28th ??? > I make the mailing list on sourceforge > subscribable by anybody. (Now, subscription is not allowed.) > So you can start subscribing that mailing list. But you cannot > directly post a message to the list. You have to post to the > current list op...@cs.... > > Subscription is just one click on this page: > > https://lists.sourceforge.net/lists/listinfo/opencxx-users > > (Between April 21 and May 6th, you will receive duplicated messages > from the two lists.) > > - Monday May 5th, you can start posting a message to the list on > sourceforge. The old list stops distribution but it forwards > a posted message to the list on sourceforge. > > - End of May, I close the old list. Could you set up auto-reply on the old address for some time (3 months?) with a link to the new list? Thanks Grzegorz > > If anyone has objection, I'll start this process. > > I really thank all of you for subscribing this mailing list for long time! > > Chiba > > ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: Alessandro P. <pa...@pn...> - 2003-04-24 13:46:13
|
Dear Grzegorz, Thanks for your offer of assistance. > > I have just downloaded OpenC++ (version 2.5.12). I would like to use > > it on my PC under Windows2000 and with Microsoft Visual Studio 7.0. > > > > I had no problems constructing the occ and gc executables using the > > makefiles provided with the OpenC++ delivery. However, when I try to > > execute the makefile for the sample programs, I get the following > > fatal error: > > > > stddef.h(84) : parse error before 'intptr_t ; ' > > Can you send the line 84 of your stddef.h (and several lines around)? I have attached the entire stddef.h file. Please note that I tried making the sample programs with version 6.0 of Microsoft Visual Studio and found that everything worked fine. Hence, the issue is not urgent (at least not as far as I am concerned)! Regards, Alessandro |
|
From: Shigeru C. <ch...@is...> - 2003-04-24 06:07:11
|
Dear OpenC++ mailing list subscribers: As you may notice, this list is currently maintained in a weird way. The posted messages are distributed by a mail server in Tokyo while they are archived by sourceforge.net. This is why you receive some annoying messages from sourceforge.net if you post a message. Since none seems to have objection to my last message, I would like to close op...@cs... and ask you all to subscribe ope...@li.... Although I asked long time ago the sourceforge admin to register all the current subscribers, they seem very busy. So I think that all of us subscribe the list by ourselves would be good. It is also good since some subscribers may want not to receive messages any more. Here is my idea: - Next monday April 21st, I make the mailing list on sourceforge subscribable by anybody. (Now, subscription is not allowed.) So you can start subscribing that mailing list. But you cannot directly post a message to the list. You have to post to the current list op...@cs.... Subscription is just one click on this page: https://lists.sourceforge.net/lists/listinfo/opencxx-users (Between April 21 and May 6th, you will receive duplicated messages from the two lists.) - Monday May 5th, you can start posting a message to the list on sourceforge. The old list stops distribution but it forwards a posted message to the list on sourceforge. - End of May, I close the old list. If anyone has objection, I'll start this process. I really thank all of you for subscribing this mailing list for long time! Chiba |
|
From: Shigeru C. <ch...@is...> - 2003-04-24 04:38:58
|
I forward this message since it's non-member submission(?). - Chiba |
|
From: stan <st...@uc...> - 2003-04-23 20:36:03
|
Grzegorz Jakacki wrote: >On Thu, 10 Apr 2003, stan wrote: > > > >>Hi, >> >>Another student and myself are having problems with the 2.6.1 release. >> >>we are using: >>Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs >>gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) >> >> >>The installation proceeds without any errors. >> >>when we try to build the samples by running "make all" >>we get the following result: >> >>../src/occ -m -I../gc -I../src -- -g VerboseClass.mc >>../src/occ -- -g -o person person.cc >>lt_dlopen(VerboseClass.so) failed: ./VerboseClass.so: undefined symbol: >>__tiQ27Opencxx5Class >>make: *** [person] Error 1 >> >>we are both having the same error. >> >>Also when working with my previous project I get a similar error with >>version 2.6.1 while version 2.5.12 works perfectly. >> >> >>any ideas? >> >> > >The samples have not been updated after build procedure have changed and >libtool library has been introduced. I think that in your case it is >enough to add '.' to LD_LIBRARY_PATH. I would suggest that you try this >and let me know if it works for you. > >BR >GJ > >PS: The honest solution involves redoing shared libraries handling by occ. > It has been discussed about a month ago, that occ should use libtool > to create libraries. > > > > >>thanks >> >> >> >> >> > >################################################################## ># Grzegorz Jakacki Huada Electronic Design # ># Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # ># tel. +86-10-64365577 x2074 Beijing 100015, China # ># Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # >################################################################## > > > > Thanks for replying. I do have '.' in my LD_LIBRARY_PATH. Also, it seems to be finding the file: ./VerboseClass.so: undefined symbol: __tiQ27Opencxx5Class It appears that it finds the file just fine, but that it encounters and undefined symbol in the file. -stan |
|
From: James M. D. <mdu...@ya...> - 2003-04-23 15:47:32
|
--- Stefan Reuther <sr...@ma...> wrote:
> On Mon, Apr 14, 2003 at 04:32:57AM -0700, James Michael DuPont wrote:
> > --- Stefan Reuther <sr...@ma...> wrote:
> > > Another possibility would be to put that knowledge into the
> > > Walker interface. Here, we have such a thing for
> > > PtreeDeclaration. Depending upon whether a PtreeDeclaration is a
> > > class declaration ("class foo;"), a name declaration ("int x;")
> > > or a function implementation ("void x() { }"), it nicely
> > > dissects the tree node and calls different functions. "Class"
> > > and "ClassWalker" already seem to do some other parts of this.
> >
> > The walker has only one problem.
> > It does not only walk, but also has to interpret things.
> > It has to know how to extract the data out of the parser
> >
> > How do you propose to hide the details of the parser from the
> walker?
>
> I would not hide the details.
>
> Someone has to know about the Ptree structure, right? My point
> was making Walker the one who knows it.
>
> Like this:
> // users can override this method
> virtual Ptree* TranslateNamespaceCooked(Ptree* keyword,
> Ptree* name,
> Ptree* content);
> // this method is called by PtreeNamespace::Translate
> virtual Ptree* TranslateNamespaceRaw(PtreeNamespace* p) {
> return TranslateNamespaceCooked(p->Car() /* "namespace" */,
> p->Second() /* the namespace
> name */,
> p->Third() /* the contents
> */);
> }
>
> I'm not exactly sure, but maybe that's not too flexible (one
> can't inspect a given Ptree except by making a custom Walker and
> calling it).
Ok, that is one way to do this.
>
> The other solution,
> class PtreeNamespace : public Ptree {
> public:
> Ptree* GetKeyword() { return Car(); }
> Ptree* GetName() { return Second(); }
> Ptree* GetContent() { return Third(); }
> };
> puts that knowledge into the Ptree itself, which I like, but I
> feel there are performance problems for things like "GetName" in
> a PtreeDeclarator (it has to skip over a number of "*", "&",
> "class::*" and cv-qualifiers to find the name or sub-declarator).
> But maybe that's not at all a problem (caching?).
I like that better. I dont want to have to make two passes to have a
clean model.
>
> Using handle classes (Grzegorz' way) would definitely work nice,
> but it's a lot of work to implement it.
I dont know yet what the handle classes would look like. The idea
sounds good. In the end we need to have to hide this whole first and
second interface.
I like the idea of a XML/DOM like structure that also allows for
lookups on the names. Each type of node that we know about gets a
proper c++ class that is attached to the generic node :
so it looks like this :
ptree -->pImp--> TreeClassDecl
the TreeClassDecl is the class that implements the classdecl
information. The ptree is the generic tree. The pImp points to the
TreeClassDecl because you may have to delete and recreate the
implementation class.
what do you think?
mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
|
|
From: James M. D. <mdu...@ya...> - 2003-04-23 15:26:59
|
--- Grzegorz Jakacki <ja...@he...> wrote: > On Mon, 14 Apr 2003, James Michael DuPont wrote: > > [...] > > 1. the preprocessor > > 2. the lexer > > 3. the yacc > > 4. the trees (ast in gcc) > > 5. the rtl (in gcc) > > 6. the debug information(in gcc) > > > > All of these are just producing messages. > > we need to have a callback filtering system so that the user can > > register and subscribe to get the information needed. That will > > predicate a identifier system that allows addressing of any part of > the > > system with an identifier. > > > > This query system could be just a set of callbacks, each callback > would > > be a differnet type of function. > > > > of course that could be made into a set of classes with methods you > can > > override. Maybe even a generic function that would allow you to get > a > > fully instanciated object of a given type. > > In the framework I have in mind there is no callback registration. > The user of the framework supplies an object whose type is a class > with > overloaded operator(). Overloads are distinguished based on the > kind of nodes in the tree. Kinds of nodes can be just nodes types, > but not necessarily --- one kind can be implemented by many types > and vice versa. The framework takes tree node implementation, decides > what kind is it and calls the appropriate overload on user-supplied > object. So that is a form of a callback. By passing an object that supports a given interface where virtual methods are called, you have a call back scenario. > > > The treecc is good for defining all the types of nodes. the > question of > > limiting the view and scope of data is a separate one. > > I do not think that there is the universal set of types of nodes, > perhaps > cons/nil is the only common denominator. It is very much domain > dependent > and the framewok should not fix it. Take a look at SLT, which defines > just > requirements on types (concepts) of containers. STL algorithms can be > used > with any types, not only the ones defined in STL (standard > containers' > iterators). For an example: imagine somebody prepared universal set > of nodes > for C++ before Chiba invented OpenC++. Now comes Chiba and wants to > have > some nodes which represent arbitrary chunks of text inserted into C++ > parse > tree. Then he should create new nodes derived from the right part. (or supply template classes as you point out) >It is very unlikely, that the person who focused on inventing > "universal" C++ parse tree predicted Chiba's requirement. We are in > similar > situation. I am not saying we should handle all the nodes, but the ones we know about. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: Stefan R. <sr...@ma...> - 2003-04-23 14:12:19
|
On Mon, Apr 14, 2003 at 04:32:57AM -0700, James Michael DuPont wrote:
> --- Stefan Reuther <sr...@ma...> wrote:
> > Another possibility would be to put that knowledge into the
> > Walker interface. Here, we have such a thing for
> > PtreeDeclaration. Depending upon whether a PtreeDeclaration is a
> > class declaration ("class foo;"), a name declaration ("int x;")
> > or a function implementation ("void x() { }"), it nicely
> > dissects the tree node and calls different functions. "Class"
> > and "ClassWalker" already seem to do some other parts of this.
>
> The walker has only one problem.
> It does not only walk, but also has to interpret things.
> It has to know how to extract the data out of the parser
>
> How do you propose to hide the details of the parser from the walker?
I would not hide the details.
Someone has to know about the Ptree structure, right? My point
was making Walker the one who knows it.
Like this:
// users can override this method
virtual Ptree* TranslateNamespaceCooked(Ptree* keyword,
Ptree* name,
Ptree* content);
// this method is called by PtreeNamespace::Translate
virtual Ptree* TranslateNamespaceRaw(PtreeNamespace* p) {
return TranslateNamespaceCooked(p->Car() /* "namespace" */,
p->Second() /* the namespace name */,
p->Third() /* the contents */);
}
I'm not exactly sure, but maybe that's not too flexible (one
can't inspect a given Ptree except by making a custom Walker and
calling it).
The other solution,
class PtreeNamespace : public Ptree {
public:
Ptree* GetKeyword() { return Car(); }
Ptree* GetName() { return Second(); }
Ptree* GetContent() { return Third(); }
};
puts that knowledge into the Ptree itself, which I like, but I
feel there are performance problems for things like "GetName" in
a PtreeDeclarator (it has to skip over a number of "*", "&",
"class::*" and cv-qualifiers to find the name or sub-declarator).
But maybe that's not at all a problem (caching?).
Using handle classes (Grzegorz' way) would definitely work nice,
but it's a lot of work to implement it.
Stefan
|
|
From: Grzegorz J. <ja...@he...> - 2003-04-23 13:44:31
|
On Mon, 21 Apr 2003, Alessandro Pasetti wrote: > I have just downloaded OpenC++ (version 2.5.12). I would like to use > it on my PC under Windows2000 and with Microsoft Visual Studio 7.0. > > I had no problems constructing the occ and gc executables using the > makefiles provided with the OpenC++ delivery. However, when I try to > execute the makefile for the sample programs, I get the following > fatal error: > > stddef.h(84) : parse error before 'intptr_t ; ' Can you send the line 84 of your stddef.h (and several lines around)? > Can anyone help me? Let's hope so :-) Regards Grzegorz > > Regards, > Alessandro > ################################################################## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # ################################################################## |
|
From: Grzegorz J. <ja...@he...> - 2003-04-23 13:43:06
|
On Wed, 16 Apr 2003, Shigeru Chiba wrote:
>
> I forward this message to the list.
>
> - Chiba
>
> From: "michael" <mic...@pa...>
> Subject: Bug in latest version of OpenC++ on sourceforge
> Date: Wed, 16 Apr 2003 13:01:20 +0200
>
> > Hi,
> >
> > i think there is a small bug in token.cc.
> > Somebody added this line to rw_table :
> >
> > { "char", token(CHAR) },
> > { "wchar_t", token(WCHAR) }, <-----------------------
Fixed.
Grzegorz
> > { "class", token(CLASS) },
> >
> > The array is no longer in alphabetical order. As a result, the binary search
> > for keywords sometimes fails.
> >
> > regards,
> > michael
>
>
##################################################################
# Grzegorz Jakacki Huada Electronic Design #
# Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074 Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################
|
|
From: Stefan S. <se...@sy...> - 2003-04-23 13:38:50
|
Grzegorz Jakacki wrote: > It is possible that gc is making problems with gcc-3.x (somebody posted > similar symptoms here). In such case please try to upgrade to the newest > stable gc and try if it works for you. The synopsis project (http://synopsis.sf.net) project is using a modified version of OpenC++ inside a (python) plugin, and we run into a number of problems related to the garbage collector. The solution was to avoid the use of global objects, as the real cause of all the trouble was undefined initialization order. Regards, Stefan |
7 messages has been excluded from this view by a project administrator.
