Menu
▾
▴
clisp-devel
|
From: Sam S. <sd...@gn...> - 2017-10-18 22:16:09
|
> * CLISP - an ANSI Common Lisp Mercurial repository <ab...@py...g> [2017-10-18 21:41:25 +0000]: > > Fix build failure with pre-C99 compilers (regression from 2008-10-29). > > By Bruno Haible on 10/18/2017 18:21 > [**View Changes**](https://sourceforge.net/p/clisp/clisp/ci/77f89d0b1b04cd53d2f1d9bed6bd264809e5a456/) I thought we decided to require C99? -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://islamexposedonline.com http://thereligionofpeace.com http://jij.org Sex is a chemical reaction; alcohol is its catalyst. |
|
From: Bruno H. <br...@cl...> - 2017-10-18 23:12:58
|
> > Fix build failure with pre-C99 compilers (regression from 2008-10-29). > > I thought we decided to require C99? Yes, a couple of months ago I too thought we would lose no porting targets by assuming C99 or better. But I had forgotten about IRIX 6.5, where the only available compiler for the 'o32' ABI is cc (at least on the machine I have access to), and this cc does not grok statements after declarations. Anyway, this pre-C99 support is not a lot of trouble. It's more time-consuming to fix the various GC crashes that I'm observing on the various porting targets... Bruno |
|
From: Sam S. <sd...@gn...> - 2017-10-19 19:19:53
|
> * Bruno Haible <oe...@py...t> [2017-10-19 01:12:48 +0200]: > >> > Fix build failure with pre-C99 compilers (regression from 2008-10-29). >> >> I thought we decided to require C99? > > Yes, a couple of months ago I too thought we would lose no porting targets > by assuming C99 or better. But I had forgotten about IRIX 6.5, where the > only available compiler for the 'o32' ABI is cc (at least on the machine > I have access to), and this cc does not grok statements after declarations. https://gcc.gnu.org/wiki/CompileFarm does not have any IRIX. If you give them IRIX, you might have gcc on it... > Anyway, this pre-C99 support is not a lot of trouble. This prevents us from dumping varbrace, so it's kinda big deal. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://www.memritv.org http://islamexposedonline.com Whether pronounced "leenooks" or "line-uks", it's better than Windows. |
|
From: Bruno H. <br...@cl...> - 2017-10-19 20:09:08
|
Sam wrote: > > Anyway, this pre-C99 support is not a lot of trouble. > > This prevents us from dumping varbrace, so it's kinda big deal. No. Until we can also remove 'gctrigger', removing 'varbrace' does not have a significant benefit. (We had this discussion already.) Bruno |
|
From: Sam S. <sd...@gn...> - 2017-10-19 21:35:45
|
> * Bruno Haible <oe...@py...t> [2017-10-19 22:08:58 +0200]: > > Sam wrote: >> > Anyway, this pre-C99 support is not a lot of trouble. >> >> This prevents us from dumping varbrace, so it's kinda big deal. > > No. Until we can also remove 'gctrigger', How can that ever happen?! > removing 'varbrace' does not have a significant benefit. The huge benefit is that C files will look like normal C. Removing varbrace and comment5 (what does "5" stand for, btw?) is just as important for CLISP as making cua-mode the default for Emacs. ;-) > (We had this discussion already.) yes, and I disagree with you. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://jij.org http://www.memritv.org http://americancensorship.org http://think-israel.org Never argue with an idiot: he has more experience with idiotic arguments. |
|
From: Bruno H. <br...@cl...> - 2017-10-19 23:28:34
Attachments:
highlight.png
|
Sam wrote: > > removing 'varbrace' does not have a significant benefit. > > The huge benefit is that C files will look like normal C. This would not be a benefit. It would be a drawback. During development, it is important to see all local variable declarations, in an easy way. With plain C syntax, neither Emacs nor kate can do this. Most probably, because the C syntax is a bit ambiguous. Whereas with 'var' syntax, editors can do this (see attached screenshot). For this reason, plain C syntax without 'var' is inferior. Even if many people use it. > Removing varbrace and comment5 (what does "5" stand for, btw?) is just > as important for CLISP as making cua-mode the default for Emacs. ;-) You can remove comment5, if you or someone else converts the comments in the remeining files (mostly lisparit.d and its include files) in a sensible way - not in a cheap automated way. I now prefer to write #if 0 #define foo bar #endif over # define foo bar And comments are well highlighted in today's editors (because the C commment syntax is unambiguous). Bruno |
|
From: Sam S. <sd...@gn...> - 2017-10-20 15:23:39
Attachments:
spvw.d.png
|
> * Bruno Haible <oe...@py...t> [2017-10-20 01:28:20 +0200]: > > Sam wrote: >> > removing 'varbrace' does not have a significant benefit. >> >> The huge benefit is that C files will look like normal C. > > This would not be a benefit. It would be a drawback. People are put off by the weird *.d extension (which falsely hints in the direction of the D language). People are put off by the gratuitous syntax modifications. People keep telling you that and you are ignoring them. > During development, it is important to see all local variable > declarations, in an easy way. Yep - just like all the other syntax highlighting. > With plain C syntax, neither Emacs nor kate can do this. I have never used kate/pico/nano/axe/... Emacs & VIM handle C syntax highlighting just fine (and MultiEdit did 25 years ago). Even the extra CLISP types are handled with the clisp/emacs/d-mode.el and clisp/emacs/d.vim extensions (and, before you ask, if we move to *.c from *.d, it would be _easier_ to handle them). > Most probably, because the C syntax is a bit ambiguous. C syntax is trash, but Emacs & VIM handle it just fine. > Whereas with 'var' syntax, editors can do this (see attached screenshot). I removed those "var" markers in Emacs and created a screenshot. Enjoy. |
|
From: <Joe...@t-...> - 2017-10-24 15:12:18
|
Hi, >It's more time-consuming to fix the various GC crashes that I'm observing >on the various porting targets... Some summary/stats would be nice at the end of your work: How much was caused by individual bugs in GCC, how much by subtly broken definitions in CLISP in some configurations. BTW, the other day I had a feeling that some of the commit logs should mention in their one liner summary that they are specific work-around for bugs in (current versions of) GCC. The summary was overly general, whereas the patch actually and really was a work around for some particular version of GCC on some particular machine or OS. This annoyed me, since perhaps next year, GCC may be fixed, however the work-around in CLISP will likely remain for 10 years. E.g. "Fix build failure on Linux/s390x." https://sourceforge.net/p/clisp/clisp/ci/c845e414641a5c4805285f38239606c9b1397964/ but what it actually does is compile lisparit.c with -O1 instead of the normal -O2. There's no configure check for it, it's simply hard-coded. Same for eval.c with -O0 in some configurations. makemake.in reads: if [ $f = eval -a "$cpu" = ia64 -a $XCC_GCC = true ] ; then # gcc-2.96 on Linux/ia64 miscompiles eval.d when -O is used. flags2=$flags2' -O0' fi gcc-2.xx? Even on my Amiga, I had something newer ;-) -O0 for eval.d which contains the bytecode interpreter -- that must hurt performance! (I'm not suggesting that configure should check for it, I'm just saying that it would be useful for packagers to be able to identify work-arounds easily. Makemake.in counts 4300 lines, and the above is lost within them.) Regards, Jörg |
|
From: Bruno H. <br...@cl...> - 2017-10-24 18:33:08
|
Hi Jörg, > Some summary/stats would be nice at the end of your work: How much was caused > by individual bugs in GCC, how much by subtly broken definitions in CLISP in > some configurations. So far, at least 2/3 of the effort is spent on, like you say, "subtly broken definitions in clisp", and less than 1/3 on miscompilation by GCC. > There's no configure check for it, it's simply hard-coded. Yes. Do you have another suggestion? > (I'm not suggesting that configure should check for it, I'm just saying that it would be > useful for packagers to be able to identify work-arounds easily. What would you suggest to achieve this? Bruno |
|
From: <Joe...@t-...> - 2017-10-25 14:22:31
|
Hi, >> There's no configure check for it, it's simply hard-coded. >Yes. Do you have another suggestion? >> (I'm not suggesting that configure should check for it, I'm just >> saying that it would be useful for packagers to be able to identify work-arounds easily. >What would you suggest to achieve this? Just names. Perhaps "HACK:" as a prefix in the one-liner log message would be enough to raise attention. Or TRICK or WA (work-around) or whatever convention. -> HACK: Fix build failure on Linux/sparc64: Disable optimizations in eval.d The keyword HACK could be repeated in makemake.in Likewise, I felt uncomfortable about this log message: < Make intparam.c compile with g++ >= 6. -> Make intparam.c compile with g++ >= 6. The "auto" specifier changed with C++11. Intparam and g++ 6 are symptoms -- or noise. "auto" is the root cause. It appears C++ now interprets "auto" as a type specifier, whereas it used to (and still does in C) indicate a storage class (like static or register). Therefore, "auto int i = 0;" is old fashioned code in C, whereas it has become incorrect in C++14 because of the redundancy: either you write e.g. int i =..., or you let the compiler derive the type, and write auto i = ...; OTOH, my experience is that few people read history. Therefore good descriptions in log messages are often in vain and arguably lost effort. Furthermore, somebody encountering this issue is more likely to google the symptoms, e.g. "intparam.c won't compile with g++" rather than guess the cure, e.g. "auto changed in C++". Regards, Jörg |
|
From: Sam S. <sd...@gn...> - 2017-10-25 18:16:58
|
Hi Jörg, > * <Wbret-Plevy.Ubruyr@g-flfgrzf.pbz> [2017-10-25 14:22:17 +0000]: > > Likewise, I felt uncomfortable about this log message: > < Make intparam.c compile with g++ >= 6. > -> Make intparam.c compile with g++ >= 6. The "auto" specifier changed with C++11. > Intparam and g++ 6 are symptoms -- or noise. "auto" is the root cause. Yes, I requested on multiple occasions that Bruno includes the full ChangeLog entry into the Mercurial commit message, like they do in, e.g., Emacs. Thanks for your support. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://no2bds.org http://islamexposedonline.com http://thereligionofpeace.com Lisp is a way of life. C is a way of death. |
|
From: Bruno H. <br...@cl...> - 2017-10-25 18:27:58
|
Hi Jörg, > Just names. Perhaps "HACK:" as a prefix in the one-liner log message would be > enough to raise attention. Whereas I thought about mentioning these things in the advice for porters file, namely unix/PLATFORMS... > Likewise, I felt uncomfortable about this log message: > < Make intparam.c compile with g++ >= 6. > -> Make intparam.c compile with g++ >= 6. The "auto" specifier changed with C++11. > Intparam and g++ 6 are symptoms -- or noise. "auto" is the root cause. Yes, "auto" is the root cause. But root cause analysis and other technical explanations belong in comments. A log message should indicate what has changed (from the point of view of the user). In this case: intparam.c did not compile and now it compiles again. > in C++14 because of the redundancy: either you write e.g. int i =..., or you > let the compiler derive the type, and write auto i = ...; Thanks for explaining. They have reused a keyword to mean a completely different thing. As usual in C++... Whereas in C# and Java it's called 'var'. Bruno |
×
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