New function for tcllib

[Christian Gollwitzer]

Hi,

what is the process to get something integrated into tcllib? I've
developed a function in pure Tcl to apply patches in unified diff
format, which is the current standard for patches (diff -ruN old/ new/)
to a source tree. This could be a useful addition, maybe as
fileutil::patch or similar.

It was developed for use in kbs wiki.tcl.tk/18146 and is available at
the bottom of the page http://wiki.tcl.tk/12586

Some polishing is still needed before this can be a universal patch
replacement:

* Parsing of diff headers should be more robust; patch actually
evaluates the diff flags to decide upon the diff format (context,
unified, normal, ed,...)

* Hunks are only applied if they match exactly. Offsets could be
implemented relatively easily. What should happen if a hunk does not
match or is already applied? In kbs, it is ignored. Maybe optional flags
should guide this

* Log output is sent to stderr ("Patching file", "hunk #N failed") etc.
Maybe use a logger module from tcllib?

Christian

[Christian Gollwitzer]

Am 12.08.15 um 20:10 schrieb Heinz-Jürgen Oertel:> Christian Gollwitzer
wrote:

>
>> what is the process to get something integrated into tcllib? I've
>> developed a function in pure Tcl to apply patches in unified diff
>> format, which is the current standard for patches (diff -ruN old/ new/)
>> to a source tree. This could be a useful addition, maybe as
>> fileutil::patch or similar.
>
>

> Don't ge me wrong, I like tcl much,
> but why not using exec patch
> and using tcl only as the clue language, as indented by the inventor?
>

Yes, this also works, provided that a suitable patch progam is
installed. But a library always gives you more fine-grained control over
the process. For instance, on error conditions the usual GNU patch
program stops and asks the user for advice, for instance if the patch
should be applied in reverse, or if a filename is missing, it puts
nonsuccessful hunks into reject files etc. In a non-interactive program
this would be undesirable, and if you are writing a code editor than you
would need to use expect to redirect those questions to the GUI. A
Tcl-only implementation can also work on virtual file systems or strings
instead of files. The algorithm is simple enough (my implementation on
http://wiki.tcl.tk/12586 is just ~200 lines) that reinventing the wheel
is not the biggest obstacle here. And there is already a diff function
in tcllib, albeit buried under struct::list::longestCommonSubsequence.

PS: I prefer to contiue discussion on this public list

[heinrichmartin]

On Thursday, August 13, 2015 at 8:36:04 AM UTC+2, Christian Gollwitzer wrote:
> the process. For instance, on error conditions the usual GNU patch
> program stops and asks the user for advice, for instance if the patch
> should be applied in reverse, or if a filename is missing, it puts
> nonsuccessful hunks into reject files etc. In a non-interactive program

Hmmm, this reminds me of my usage of "ssh user@host". When it came to automation, I first struggled with different versions that require "yes" or "y" as answer to fingerprint questions.

But in the end, I just RTM to come up with what I intended:
set pid [spawn -noecho ssh \
-o UserKnownHostsFile=/dev/null \
-o ServerAliveInterval=$alive \
-o StrictHostKeyChecking=no \
-o NumberOfPasswordPrompts=1 \
$username@$host \
]

patch has several options for non-interactive processing, too. I know there are other reasons pro library (availability, portability), but interactive mode is none of them.

> instead of files. The algorithm is simple enough (my implementation on
> http://wiki.tcl.tk/12586 is just ~200 lines) that reinventing the wheel
> is not the biggest obstacle here. And there is already a diff function

... and some modules provide a Tcl implementation as back-up when libraries are not available at the target system ...

> PS: I prefer to contiue discussion on this public list

:-)

[Andreas Kupries]

Christian Gollwitzer <auri...@gmx.de> writes:

> Hi,
>
> what is the process to get something integrated into tcllib? I've

Go to
http://core.tcl.tk/tcllib

and submit a ticket. Disregard this if you have already done so.
(I have not looked at Tcllib in some time, hope to have some hours for
going over its tickets in two weeks)

--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://core.tcl.tk/akupries/>
Developer @ HP Enterprise

Tcl'2015, Oct 19-23, Manassas, VA, USA, http://www.tcl.tk/community/tcl2015/
-------------------------------------------------------------------------------