Re: How to globally replace core binding?

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2001 bytes --]

> [...]
> It looks like it is defined inside libguile/filesys.c, so that is not an option.
> And I would like to avoid patching the Guile itself anyway.

In that case, this part is N/A.

>> That way, Guile's compiler/optimizer knows that the binding is mutable and
>> should not inlined (well, Guile being Guile, every binding is mutable, but
>> now it is mutable from the perspective of the inliner too).
> Interesting, is there a way to do the same hint from the C code?  Would there be
> a reason?  I assume C code cannot be inlined anyway, so there is no need?

It would theoretically be possible to implement cross C<->Scheme 
inlining, but given that no such inlining exists currently, there is no 
method for declaring ‘don't inline’ and no need.

>> Depending on whether 'copy-file' is just a stand-in for something else and
>> depending on how the better copy-file works/how it is ‘better’, it might be
>> better to eventually write a patch to replace copy-file with the improved
>> better-file, as then the improved copy-file is more widely available. (As a
>> long-term thing; for short-term ‘trying things out’, doing set! is much more
>> practical.)
> What I want to do is to replace (copy-file oldfile newfile) by modified version
> with signature (copy-file oldfile newfile [reflink]) with reflink defaulting to
> 'auto (see man cp for details).
> 
> I expect this to be a somewhat controversial change, so I did not intend to send
> a patch, however I can, if you think it has a chance of getting merged.
> 
> Tomas

An extra reflink argument seems fine to me, though I would use a keyword 
argument #:copy-on-write instead -- a bit more flexible towards 
potential future API additions (#:sparse? #true #:user [UID] #:group 
[GID] #:mode [...] ...).

Worst case, someone disagrees that 'auto' should be the default, but 
merely adding the _option_ to copy-on-write would be uncontroversial, I 
think.

Best regards,
MAxime Devos.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]