Richard Fateman <fateman at eecs.berkeley.edu> writes:
>> furthermore git uses patches compatible with patch(1), thus one can
>> just cd to the directory with sources (not necessary git-cloned) and
>> do
>>
>> $ patch -p1< patch-file-to-apply
>
> Again, this is a retrograde approach to software development, assuming
> that the real way to make a "fix" is to change the source file, and
> re-make the whole world.
A serious question: Can you explain exactly what you mean by
"retrograde" here?
>>> Here is the kind of thing that would be useful. You come up with
>>> a good idea that other people might want to try out without
>>> recompiling maxima etc etc. Create a file that can be read in
>>> like this:
>>>
>>> ;;; file defining new feature xxx
>>> ;;; written by<author> <date>
>>> ;;; tested in Maxima<version>
>>>
>>> (in-package :maxima)
>>>
>>> ;;; redefine two functions in file simp.lisp
>>
>> The problem with this approach is that unless the format is
>> standardized and the tools are written, it requires a human
>> intervention "to apply such a patch" -- tedious and error-prone.
>
> There are no tools necessary other than a text editor, to make this file.
And then how do you propose to integrate it with the other code in the
system when you decide to keep the change?
>> By the way, just file name is not enough, one also needs to mention
>> where to put the functions in each file when the patch is "applied".
> If someone wishes to make the changes to the source file, yes, one
> would have to
> search for
> (defun xxx .....)
>
> or perhaps (defmfun xxx ...)
>
> delete the definition and insert the new one.
Don't forget that the brittleness of patches also serves another
purpose: if other bits of the file have changed, they might well have
changed how your defun/defmfun will behave, rendering it incorrect even
though your code didn't change at all. This is particularly problematic
if there are lots of dynamic variables floating around... like in
Maxima.
>>> I continue to object generally to patches and files whose authorship
>>> can be discerned only by examining the separate change logs, so any
>>> alterations to pre-existing functions should have comments
>>> identifying authors, too.
>>
>> Why do manually what a program can do? Git has git-blame(1) if one
>> wants to know who to blame for each line.
> Why do I have to install git and become an expert in it?
"Oh no. In order to write a computer program, I'll have to learn to use
an editor, which is orthogonal to the important business of coding and
learning to use a programming language."
How is your standpoint different from this caricature?
<snip>
>
> Also the description says that this will not help for lines that were
> deleted or replaced. Knowing the author of a line also does not
> necessarily provide a comment as to why the new line is superior to
> the old.
Yep. That's what commit logs are for.
> I also sometimes print out programs to read / revise them, and take
> them away from a computer. It is nice to have the program text provide
> relevant comments, in my opinion.
Ok, well I guess we disagree here. For me, a file containing source code
is not required to be a detailed "biography" of the history of the
project.
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120601/40ee7258/attachment.pgp>;