Re: [Tinycc-devel] Please, please at least notify the list when you make big changes

[grischka]

David Mertens wrote:
> Case in point:
>
> I just tried to merge grischka's latest commit, described as "tccgen: 
> nodata_wanted fix, default ONE_SOURCE, etc...". I have no idea why, but 
> with the commit grischka decided to move a whole bunch of functionality 
> out of libtcc.c's tcc_compile() and into tccgen.c's tccgen_compile(). Is 
> this a good idea? Maybe? It makes tcc_compile read a little more 
> clearly, though the real functionality is now buried under one more 
> layer of abstraction. I don't know grischka's motivation because he 
> never explained what he's doing or why.

IIRC "common setjmp clause" was the argument, as noted in the commit
comment.

> What I do know is that now two of my tests segfault, and I'll probably 
> have to spend a couple of *hours* reverse-engineering how to track the 
> symbols.
>
> Hours of my life wasted for what seems like a frivolous change.

David, be sure that for a moment I thought about your extsyms when
doing exactly this change, but sorry, for one it had to be and two
it does not make sense to base decisions on possibly existing forks
elsewhere.

See, once at some point in the past I suggested to you, rather than
a flag on the type to use a flag or pointer in the tokensym instead
which in my impression would behave much more orthogonal and friendly
wrt. maintenance.

And your answer was like "hm no, I like it please, because of the
smaller memory footprint,..." or so.  Okay man, right.  But then don't
complain with me because of merge pains.  All I was trying to say
is that "Hours of life" might be a valid argument when traded against
4 bytes more per symbol, and that some thoughts or maybe even hours
spent once on a effective defense strategy against upstream changes
might be a good investment at some point ... ;)

--- grischka

> David
>
> On Tue, Jul 25, 2017 at 12:31 AM, David Mertens 
> <address@hidden <mailto:address@hidden>> wrote:
>
>     Hello all,
>
>     This is my annual (or so) rant/reminder urging everyone for high
>     quality committing and communicating habits.
>
>     As a maintainer of a fork of tcc, I go through a lot of effort when
>     I merge the latest work on tcc's mob into my fork. This is a burden
>     I have brought upon myself, and I am not complaining about folks'
>     contributions to tcc that continue to improve it. However, there are
>     ways to improve things (i.e organize, commit, and discuss your work)
>     that are easy to process, and there are ways to improve things that
>     are hard to process.
>
>     If you want to see practices that are easy to process, look at
>     Michael Matz's commits and the conversation surrounding them. If you
>     want to see commits that are hard to process, see grischka's
>     unprompted commits.
>
>     Let me be clear before I go any further: the final result of
>     grischka's commits are almost universally excellent. He wields C
>     much better than I ever could, and I would rather have his commits
>     as he currently does them than not have them at all. Specifically,
>     grischka latest work refactoring the Sym layout is a fantastic
>     contribution that makes this compiler easier to understand for
>     current and future tcc hackers. It's the kind of think that
>     everybody would like to have, but nobody except grischka will put
>     the effort into doing. Thank you!
>
>     But lordy I would really appreciate if he (and the rest of the
>     community) could consider the following basic good-git practices:
>
>         * orthogonal changes should be in distinct commits, don't commit
>           "X... and also Y, Z, and W"
>         * changes to any of the internal function APIs should be (at the
>           very least) announced on the mailing list, and preferably
>           discussed
>         * changes in where and how functionality is implemented should
>           be announced on the mailing list, and preferably discussed.
>         * changes to public API functions *really* *should* be discussed
>           on the mailing list before being committed
>         * changes to the build process *really* *should* be discussed on
>           the mailing list before being committed
>
>     Why should you do these things? Because right now I cringe before I
>     try to merge any commit made by grischka. I know the result will be
>     worth it, but the interim will probably be time consuming and
>     confusing. Do you want to be cringe-inducing to fellow developers?
>     Of course not. Discuss your work on the list and commit your work in
>     lots of small chunks.
>
>     Thanks!
>     David
>
>     -- 
>      "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
>
>
>
>
> --
>  "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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel