From: Sam S. <sd...@gn...> - 2003-10-24 23:29:19
|
> * Bruno Haible <oe...@py...t> [2003-10-25 01:05:49 +0200]: > >> CLISP cannot be compiled with g++ and I have an apparent GC-safety bug >> in COPY-FILE... > > We must get DEBUG_GCSAFETY going again. If possible, I'd prefer if we can > do it without changing hundreds of > var object x = ...; > into > var object x; x = ...; well, I am not C++ expert, but I can hardly imagine that there is a C-like language where the two forms are not interchangeable -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Isn't "Microsoft Works" an advertisement lie? |
From: Bruno H. <br...@cl...> - 2003-10-27 15:21:52
|
Sam wrote: > > We must get DEBUG_GCSAFETY going again. If possible, I'd prefer if we can > > do it without changing hundreds of > > var object x = ...; > > into > > var object x; x = ...; > > well, I am not C++ expert, but I can hardly imagine that there is a > C-like language where the two forms are not interchangeable I meant it from a maintainability point of view. We want to continue to write "var object x = ...;" even though g++ 3.3 does not grok this. I've now put the corresponding preprocessing into varbrace.d. Bruno |
From: Sam S. <sd...@gn...> - 2003-10-27 15:49:30
|
> * Bruno Haible <oe...@py...t> [2003-10-27 16:19:42 +0100]: > > Sam wrote: >> > We must get DEBUG_GCSAFETY going again. If possible, I'd prefer if we can >> > do it without changing hundreds of >> > var object x = ...; >> > into >> > var object x; x = ...; >> >> well, I am not C++ expert, but I can hardly imagine that there is a >> C-like language where the two forms are not interchangeable > > I meant it from a maintainability point of view. We want to continue > to write "var object x = ...;" even though g++ 3.3 does not grok this. I looked at your patch to lispbibl.d:1.401 and my jaw dropped and damaged my toes. I am speechless. Are you seriously saying that there is a C derivative (C++/Java/C# &c) which does not accept struct foo x = { a, b, c}; as a shortcut for struct foo x; x.slot1 = a; x.slot2 = b; x.slot3 = c; this is absurd! Could you please kindly explain to me what is going on? _Why_ did they disallow this? Which languages still permit this? I am confused, dumbfounded and stunned. > I've now put the corresponding preprocessing into varbrace.d. this means that D format is there to stay.... :-( -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Linux - find out what you've been missing while you've been rebooting Windows. |
From: Bruno H. <br...@cl...> - 2003-10-27 16:23:56
|
Sam wrote: > Are you seriously saying that there is a C derivative (C++/Java/C# &c) > which does not accept > > struct foo x = { a, b, c}; > > as a shortcut for > > struct foo x; > x.slot1 = a; > x.slot2 = b; > x.slot3 = c; > > this is absurd! Yes. AFAIK, it is called ANSI C (or C89 or C90). $ rlogin a-solaris-machine $ cat > foo.c <<EOF struct foo { int a; int b; }; int sum (struct foo *p) { return p->a + p->b; } int add1 (int x) { struct foo f = { 1, x }; return sum(&f); } EOF $ cc -c foo.c "foo.c", line 6: non-constant initializer: op "NAME" cc: acomp failed for foo.c > Could you please kindly explain to me what is going on? > _Why_ did they disallow this? I guess, to make the compilers simpler. I.e. to make the initialization of structs possible via a simple 'bcopy', without dealing with intermediate expressions. > Which languages still permit this? I think C99 allows non-constant elements in aggregate initializers. C++ also allows non-constant elements in static aggregate initializers. > > I've now put the corresponding preprocessing into varbrace.d. > > this means that D format is there to stay.... :-( Yes I think the ability to work around a severe compiler problem with just a little patch in a preprocessor is a good reason to keep 'varbrace' alive. Bruno |
From: Sam S. <sd...@gn...> - 2003-10-27 16:56:58
|
> * Bruno Haible <oe...@py...t> [2003-10-27 17:20:35 +0100]: > > Sam wrote: > >> Are you seriously saying that there is a C derivative (C++/Java/C# &c) >> which does not accept >> >> struct foo x = { a, b, c}; >> >> as a shortcut for >> >> struct foo x; >> x.slot1 = a; >> x.slot2 = b; >> x.slot3 = c; >> >> this is absurd! > > Yes. AFAIK, it is called ANSI C (or C89 or C90). > > $ rlogin a-solaris-machine > $ cat > foo.c <<EOF > struct foo { int a; int b; }; > int sum (struct foo *p) { return p->a + p->b; } > int add1 (int x) > { > struct foo f = > { 1, x }; > return sum(&f); > } > EOF > $ cc -c foo.c > "foo.c", line 6: non-constant initializer: op "NAME" > cc: acomp failed for foo.c I see, so solaris cc is not c99 - don't they supply a compliant compiler? >> Could you please kindly explain to me what is going on? >> _Why_ did they disallow this? > > I guess, to make the compilers simpler. I.e. to make the initialization > of structs possible via a simple 'bcopy', without dealing with > intermediate expressions. > >> Which languages still permit this? > > I think C99 allows non-constant elements in aggregate initializers. > C++ also allows non-constant elements in static aggregate initializers. so you are saying that it's not that they suddenly forbade this, but that it has always been technically forbidden but was available as an extension from some C vendors and has now been standardized in c++ and c99. that makes sense. >> > I've now put the corresponding preprocessing into varbrace.d. >> >> this means that D format is there to stay.... :-( > > Yes I think the ability to work around a severe compiler problem with > just a little patch in a preprocessor is a good reason to keep > 'varbrace' alive. Just a second! if both C++ and C99 permit this _and_ also variables in the middle of the block, then why don't we just drop support for pre-C99? we discussed this about a year ago and you agreed in principle that this is what should be done. <http://sourceforge.net/mailarchive/message.php?msg_id=3902475> -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> usually: can't pay ==> don't buy. software: can't buy ==> don't pay |
From: Bruno H. <br...@cl...> - 2003-10-27 19:15:17
|
Sam wrote: > > I think C99 allows non-constant elements in aggregate initializers. > > C++ also allows non-constant elements in static aggregate initializers. > > so you are saying that it's not that they suddenly forbade this, but > that it has always been technically forbidden but was available as an > extension from some C vendors and has now been standardized in c++ and > c99. Right. And before ANSI C you could not even assign structs like this: struct foo instance1, instance2; instance1 = instance2; You had to use bcopy() on the addresses. (Although you could 'return' structs, and then the compiler would generate the bcopy() of the return value for you.) > > Yes I think the ability to work around a severe compiler problem with > > just a little patch in a preprocessor is a good reason to keep > > 'varbrace' alive. > > Just a second! > if both C++ and C99 permit this _and_ also variables in the middle of > the block, then why don't we just drop support for pre-C99? So few compilers do support C99. In particular, to my knowledge, MSVC 7 isn't C99 compliant. (It has none of <stdbool.h>, <stdint.h>, <inttypes.h>). So dropping C99 means dropping the WIN32_NATIVE port of clisp. Which I won't agree to. Bruno |
From: Sam S. <sd...@gn...> - 2003-10-27 19:29:27
|
> * Bruno Haible <oe...@py...t> [2003-10-27 20:12:40 +0100]: > >> if both C++ and C99 permit this _and_ also variables in the middle of >> the block, then why don't we just drop support for pre-C99? > > So few compilers do support C99. In particular, to my knowledge, MSVC > 7 isn't C99 compliant. (It has none of <stdbool.h>, <stdint.h>, > <inttypes.h>). So dropping C99 means dropping the WIN32_NATIVE port ^^^^^^^^^^^^ (you mean requiring c99 or dropping c89) > of clisp. Which I won't agree to. OK. let's just drop comment5. the reason I am so vehement against comment5 (and elif, loop, unless &c macros) is that they create too much confusion for newcomers. they look at the *.d files and feel that they will need to learn a whole new language. if comment5 is dropped, d-mode will become much more reliable. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Software is like sex: it's better when it's free. |
From: Bruno H. <br...@cl...> - 2003-10-27 20:24:57
|
Sam wrote: > OK. let's just drop comment5. > > the reason I am so vehement against comment5 (and elif, loop, unless &c > macros) is that they create too much confusion for newcomers. they > look at the *.d files and feel that they will need to learn a whole new > language. > > if comment5 is dropped, d-mode will become much more reliable. You are now mixing two different issues: the look of the sources and the need for comment5. About the "feeling to need to learn a new language". I propose to replace - "# " comments with "// " comments. They are not so visually repelling as /* ... */ comments. More precisely, /* ... */ comments look fine when preceded by blank lines (GNU style), but since we both don't like blank lines inside functions, I propose to go with //. Since // is C++ and C99, even newcomers will accept it. - Replace "elif" with "else if". I have no problem with this. - Replace "loop" with "for (;;)". This is the typical C idiom for an endless loop. - I don't acree about the "until" macro. A "while" loop often makes you think in the opposite terms; whereas "until" emphasizes the goal of a loop and an invariant after the loop. Do we still need comment5? Yes, to ensure portability to C89 compilers while using // comments we still need it. We will drop it when time has come, like we dropped ansidecl today. Bruno |
From: Sam S. <sd...@gn...> - 2003-10-27 20:32:32
|
> * Bruno Haible <oe...@py...t> [2003-10-27 21:18:25 +0100]: > > Sam wrote: >> OK. let's just drop comment5. >> >> the reason I am so vehement against comment5 (and elif, loop, unless &c >> macros) is that they create too much confusion for newcomers. they >> look at the *.d files and feel that they will need to learn a whole new >> language. >> >> if comment5 is dropped, d-mode will become much more reliable. > > You are now mixing two different issues: the look of the sources and > the need for comment5. > > About the "feeling to need to learn a new language". I propose to replace > > - "# " comments with "// " comments. They are not so visually repelling > as /* ... */ comments. More precisely, /* ... */ comments look fine > when preceded by blank lines (GNU style), but since we both don't like > blank lines inside functions, I propose to go with //. you might want to replace those comments that _are_ preceded by blank lines with /* */ > Since // is C++ and C99, even newcomers will accept it. OK. > - Replace "elif" with "else if". I have no problem with this. > > - Replace "loop" with "for (;;)". This is the typical C idiom for an > endless loop. or while(1)... > - I don't acree about the "until" macro. A "while" loop often makes you > think in the opposite terms; whereas "until" emphasizes the goal of a > loop and an invariant after the loop. OK, just one new keyword is not too bad. > Do we still need comment5? Yes, to ensure portability to C89 compilers > while using // comments we still need it. We will drop it when time > has come, like we dropped ansidecl today. OK. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The only substitute for good manners is fast reflexes. |
From: Sam S. <sd...@gn...> - 2003-10-27 21:26:41
|
> * Bruno Haible <oe...@py...t> [2003-10-27 20:12:40 +0100]: > > So few compilers do support C99. In particular, to my knowledge, MSVC > 7 isn't C99 compliant. (It has none of <stdbool.h>, <stdint.h>, > <inttypes.h>). So dropping C99 means dropping the WIN32_NATIVE port > of clisp. Which I won't agree to. CLISP compiled with mingw is faster than the one compiled with MSVC and includes modules too. I am not sure it will be such a huge loss if MSVC were dropped. OTOH, here is what I see now: (gdb) p write_helper(handle,0x223d30,len,no_hang) Breakpoint 9, write_helper (fd=0x1f, buf=0x0, nbyte=64, no_hang=false) at win32aux.d:504 i.e., write_helper() _ALWAYS_ receives NULL as the second argument!!! #4 write_helper (fd=0x1f, buf=0x0, nbyte=64, no_hang=false) at win32aux.d:504 #5 0x0048fea4 in low_write_array_unbuffered_handle (stream= {one_o = 433805289}, byteptr=0x223d30 " i i i i i i i ooooo o ooooooo ooooo ooooo\n", len=64, no_hang=false) at stream.d:5378 #6 0x00490329 in wr_ch_array_unbuffered_unix (stream_=0xf30088, chararray_=0xf3008c, start=0, len=64) at stream.d:5479 #7 0x004883e2 in write_char_array (stream_=0xf30088, chararray_=0xf3008c, start=0, len=64) at stream.d:814 #8 0x004b217d in write_sstring_ab (stream_=0xf30088, string= {one_o = 433806249}, start=0, len=64) at io.d:5076 #9 0x004b21b6 in write_sstring (stream_=0xf30088, string={one_o = 433806249}) at io.d:5087 #10 0x0041739e in print_banner () at spvw.d:1627 #11 0x00418c68 in main (argc=10, argv=0x3f2c60) at spvw.d:2717 YUK! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The only guy who got all his work done by Friday was Robinson Crusoe. |
From: Bruno H. <br...@cl...> - 2003-10-27 21:59:59
|
Sam wrote: > > So few compilers do support C99. In particular, to my knowledge, MSVC > > 7 isn't C99 compliant. (It has none of <stdbool.h>, <stdint.h>, > > <inttypes.h>). So dropping C99 means dropping the WIN32_NATIVE port > > of clisp. Which I won't agree to. > > CLISP compiled with mingw is faster than the one compiled with MSVC and > includes modules too. I am not sure it will be such a huge loss if > MSVC were dropped. OK, but nevertheless even if a build with mingw is possible (and faster, of course, since the inline assembly in eval.d works only with gcc and icc), it'd be a bad decision to put all bets on one horse (namely, gcc). I made CLN dependent on g++, and regret it! Bruno |
From: Bruno H. <br...@cl...> - 2003-11-04 21:23:52
|
Sam wrote: > OK, g++ still does not compile clisp: > > arilev1i.d:10: error: `sourceptr' was not declared in this scope Oh, I wasn't aware of that. Bruno |
From: Sam S. <sd...@gn...> - 2003-11-05 17:07:32
|
> * Bruno Haible <oe...@py...t> [2003-11-04 22:22:05 +0100]: > > Sam wrote: >> OK, g++ still does not compile clisp: >> >> arilev1i.d:10: error: `sourceptr' was not declared in this scope > Oh, I wasn't aware of that. thanks for fixing this. unfortunately, g++/DEBUG_GCSAFETY cannot compile modules: --- clisp-test-clisp.out 2003-11-04 20:49:52.825322900 -0500 +++ clisp-test-lispbibl.out 2003-11-04 20:49:52.845351500 -0500 @@ -90,29 +90,29 @@ sizeof(soint)=4 sizeof(tint)=1 sizeof(aint)=4 -sizeof(record_)=12 +sizeof(record_)=8 sizeof(Record)=4 -sizeof(lrecord_)=12 +sizeof(lrecord_)=8 sizeof(Lrecord)=4 -sizeof(srecord_)=12 +sizeof(srecord_)=8 sizeof(Srecord)=4 sizeof(cons_)=8 sizeof(Cons)=4 -sizeof(symbol_)=32 +sizeof(symbol_)=28 sizeof(Symbol)=4 sizeof(cint)=4 sizeof(chart)=4 -sizeof(bignum_)=12 +sizeof(bignum_)=8 sizeof(Bignum)=4 sizeof(ffloat)=4 sizeof(ffloatjanus)=4 sizeof(dfloat)=8 sizeof(dfloatjanus)=8 -sizeof(sbvector_)=12 +sizeof(sbvector_)=8 sizeof(Sbvector)=4 -sizeof(sstring_)=12 +sizeof(sstring_)=8 sizeof(Sstring)=4 -sizeof(svector_)=12 +sizeof(svector_)=8 sizeof(Svector)=4 sizeof(Structure)=4 sizeof(Instance)=4 @@ -128,11 +128,11 @@ sizeof(cint8)=1 sizeof(cint16)=2 sizeof(cint32)=4 -sizeof(s8string_)=12 +sizeof(s8string_)=8 sizeof(S8string)=4 -sizeof(s16string_)=12 +sizeof(s16string_)=8 sizeof(S16string)=4 -sizeof(s32string_)=12 +sizeof(s32string_)=8 sizeof(S32string)=4 sizeof(if_does_not_exist_t)=4 sizeof(if_exists_t)=4 could you please propagate g++/DEBUG_GCSAFETY code from lispbibl.d to clisp.h? thanks. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> "Syntactic sugar causes cancer of the semicolon." -Alan Perlis |