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
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
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
Every 3 month or so, I build OpenLisp on:
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of David Mertens
Sent: samedi 15 octobre 2016 18:58
Subject: [Tinycc-devel] Governance (Re: cleanups)
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?
On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin
On Sat, Oct 1, 2016 at 3:03 PM, grischka <gris...@gmx.de> wrote:
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
That also brought me to wonder how that release process would be
managed and effectively executed. Could you elaborate on that
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
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.
Tinycc-devel mailing list
"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