Thank you for your help, you really let
me say these ideological emancipation.
However, I do have a lot to improve and optimize tcc patches, I
hope you publish tcc before 0.9.27 join. I will commit as much as
possible into smaller finer. These are my thoughts now.
By the way, I forgot to ask you about me add two assert ()
reasonable?
jiang
Hey jiang,
I think there's a broader issue at play here involving
appropriate communication. I looked for some
commentary about this on the internet but could not
find it. I know I encountered it somewhere once, but I
don't remember. I'll try to state it clearly.
Distributed version systems such as git are meant to
minimize unneeded communication between developers.
If I come up with a good idea for tcc and others agree,
I don't have to send an email with the actual patch to
the mailing list. I don't have to provide instructions
for which patch sets you need to apply in order to apply
my patch. This sort of communication---how do you use my
patch---can be automated away. Git is very good at
automating away this unnecessary communication.
However, communication is important on projects with
multiple developers such as tcc. You are working on a
community effort, and you want your code to help the
community. It is important, therefore, to discuss your
ideas with the community before moving forward with them.
Maybe grishka already has some work on a feature you want.
Maybe Thomas has some implementation ideas. Maybe Daniel
could explain why none of tcc's code base uses assert. These
ideas are worth discussing, and moving forward with your
ideas without a discussion could potentially waste a
great deal of your time. Until you've made a large
number of contributions to the project, you should run any
and all ideas by the community before implementing them.
So your first step is not to write any code yet. Your first
step is to pick one (and for now, only one) idea that you
would like to implement. Perhaps its the 64-bit register
usage. Propose the idea. Summarize your idea in an email.
Ask for feedback. If others think it's a good idea,
implement it and ask for a code review, being sure to
indicate where you began your work (so it's clear where the
code review should begin).
In short, try to start off being less ambitious. :-)
David
|