Gentlemen, I will don’t blame anybody here, especially Grischka that does an amazing job.
The real issue I see with most computer languages having ports on different systems and processors is that they lack of compressive test suite and tcc is not an exception. Here, I’m not talking about the few tests that exist in tinycc/test/. If someone pushes a commit, how and when will we see that it has broken a major piece of code, like gawk, on Aarch64 or my OpenLisp compiler on Windows x64 for example? The major difficulty with a language is that it is used to compile programs we have never seen. Ideally, we should have a farm (as https://gcc.gnu.org/wiki/CompileFarm) that nightly compiles tcc on ALL supported platforms THEN uses this tcc version to compile a selected number of open source project that are known to compile with tcc THEN run test suite of those projects. That’s why I’m trying to help this project by compiling, running tests, compiling my own Lisp on as much machine/system I have access on. Unless obvious, I avoid to push anything that may break something. I prefer to ask. For a project like this, we should never remove something, especially line of code, files or tests unless we are absolutely sure. If something is there, this is probably for a very good reason. The good attitude is at least to ping community about a questionable feature. For every commit I make for my Lisp, I compile OpenLisp with 17 compiler/version/options just on Windows and for each of them I run 30000 lines of test. Every 3 month or so, I build OpenLisp on: openlisp-10.2.0-AIX-powerpc.tar.gz openlisp-10.2.0-Darwin-i386.tar.gz openlisp-10.2.0-Darwin-powerpc.tar.gz openlisp-10.2.0-Darwin-x86_64.tar.gz openlisp-10.2.0-FreeBSD-arm.tar.gz openlisp-10.2.0-FreeBSD-x86_64.tar.gz openlisp-10.2.0-Linux-armv6l.tar.gz openlisp-10.2.0-Linux-armv7l.tar.gz openlisp-10.2.0-Linux-i686.tar.gz openlisp-10.2.0-Linux-powerpc.tar.gz openlisp-10.2.0-Linux-powerpc64.tar.gz openlisp-10.2.0-Linux-powerpc64le.tar.gz openlisp-10.2.0-Linux-sparc.tar.gz openlisp-10.2.0-Linux-sparc64.tar.gz openlisp-10.2.0-Linux-x86_64.tar.gz openlisp-10.2.0-NetBSD-i686.tar.gz openlisp-10.2.0-NetBSD-x86_64.tar.gz openlisp-10.2.0-OpenBSD-i386.tar.gz openlisp-10.2.0-OpenBSD-x86_64.tar.gz openlisp-10.2.0-QNX-i386.tar.gz openlisp-10.2.0-SunOS-i386.tar.gz openlisp-10.2.0-SunOS-sparc.tar.gz openlisp-10.2.0-SunOS-sparc64.tar.gz openlisp-10.2.0-SunOS-x86_64.tar.gz openlisp-10.2.0-mingw64.zip openlisp-10.2.0-win32-x86.zip openlisp-10.2.0-win64-ia64.zip openlisp-10.2.0-win64-x86.zip openlisp-10.3.0-FreeBSD-arm.tar.gz openlisp-10.3.0-Linux-mips.tar.gz openlisp-10.3.0-Linux-mips64.tar.gz openlisp-10.3.0-Linux-mips64el.tar.gz openlisp-10.3.0-Linux-mipsel.tar.gz openlisp-10.3.0-mingw64.zip openlisp-10.3.0-win32-x86.zip openlisp-10.3.0-win64-ia64.zip openlisp-10.3.0-win64-x86.zip From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of David Mertens Sent: samedi 15 octobre 2016 18:58 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] Governance (Re: cleanups) Hello all, Jean-Claude articulates concerns I have felt as well. Sometimes we'll get a series of ridiculous commits from hitherto unknown programmers trying to "help". Sometimes we get commits from people trying to extend tcc's behavior beyond its core intent. Other times core hackers (OK, mostly just grishka) push a series of commits, some of which are brilliant and others of which are inappropriate and highly opinionated. (Overall I am glad to have grishka's contributions, but they always seem to come with a bit of avoidable pain.) I would be happy to see this project moved out of a mob branch on repo.or.cz, and managed on a site that provides facilities for collaborative programming. My experience is with github, but I don't care if it's there or somewhere else. I would just like to have contributions submitted as pull requests, and managed by one or two gatekeepers. If there is significant interest in this, I'm sure that we can start a grass-roots group. This is open source, after all. :-) So, are Jean-Claude and I mostly alone in this, or do others feel similarly? David On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin <jean.claude.beaud...@gmail.com> wrote: On Sat, Oct 1, 2016 at 3:03 PM, grischka <gris...@gmx.de> wrote: Hey all, I did push some cleanups to prepare for a release 0.9.27, eventually. Just if you wonder what's the point of that. I was indeed wondering if we would see a new release sometime soon considering that the latest one dates from a few years ago. That is answered now. That also brought me to wonder how that release process would be managed and effectively executed. Could you elaborate on that point please? One fact that gives me serious pause in that area is that the majority of the commits I contributed in the last few days were simply reverted thus reintroducing the problems they tried to fix or introducing some new lesser one when the revert was partial. A good number of others recent commits have been also similarly impacted. That leaves me quite puzzled. My intent was to use libtcc as a significant part of the back-end of MKCL <https://common-lisp.net/project/mkcl/> . But after some study of the TCC source code I came to the realization that there were a number of serious technical problems with that. And now there is this governance aspect being raised. All that push me to reconsider my approach. Regards, Jean-Claude Beaudoin _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
