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 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 
of test.

Every 3 month or so, I build OpenLisp on:
































From: Tinycc-devel [] On 
Behalf Of David Mertens
Sent: samedi 15 octobre 2016 18:58
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, 
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 
<> wrote:



On Sat, Oct 1, 2016 at 3:03 PM, grischka <> 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



That leaves me quite puzzled.


My intent was to use libtcc as a significant part of the back-end

of 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.




Jean-Claude Beaudoin


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

Reply via email to