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
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel