* process-file and Tramp's file cache (was: bug#1741: 23.0.60; vc fail to register file while logged as /su:: with tramp) [not found] ` <jwveivvrww9.fsf-monnier+emacsbugreports@gnu.org> @ 2009-08-18 10:16 ` Michael Albinus 2009-08-18 14:32 ` process-file and Tramp's file cache Stefan Monnier 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2009-08-18 10:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: Julian Scheid, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > BTW, to improve the behavior in case of things like "git status", it > might be worthwhile to add some way to indicate that a particular use of > process-file is (supposed to be) free of side-effects. I would like to introduce a new variable `process-file-modification-list'. It's default value shall be `t', which means that any file on the remote host could have been modified by the corresponding `process-file' call. `nil' means that no file is modified during `process-file'. A list of strings (remote file names) are indication, that exactly those files are modified, when `process-file' runs. This would allow Tramp to optimize its file cache. Currently, it assumes after every `process-file' call, that all cached values are invalid. This results in unnecessary check operations on the remote side. A typical use case in `vc-registered' would look like this: (let (handler process-file-modification-list) (cond ... Opinions? > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 10:16 ` process-file and Tramp's file cache (was: bug#1741: 23.0.60; vc fail to register file while logged as /su:: with tramp) Michael Albinus @ 2009-08-18 14:32 ` Stefan Monnier 2009-08-18 14:54 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2009-08-18 14:32 UTC (permalink / raw) To: Michael Albinus; +Cc: Julian Scheid, emacs-devel >> BTW, to improve the behavior in case of things like "git status", it >> might be worthwhile to add some way to indicate that a particular use of >> process-file is (supposed to be) free of side-effects. > I would like to introduce a new variable `process-file-modification-list'. > It's default value shall be `t', which means that any file on the remote > host could have been modified by the corresponding `process-file' call. > `nil' means that no file is modified during `process-file'. A list of > strings (remote file names) are indication, that exactly those files are > modified, when `process-file' runs. > This would allow Tramp to optimize its file cache. Currently, it assumes > after every `process-file' call, that all cached values are invalid. > This results in unnecessary check operations on the remote side. > A typical use case in `vc-registered' would look like this: > (let (handler process-file-modification-list) > (cond ... > Opinions? How 'bout changing Tramp's process-file to compare the command (and args) against a list of "known pure commands"? This would keep it all inside Tramp, which I think I like better (tho I also agree that this information is not fundamentally specific to Tramp, although currently Tramp is the only package able to make use of it). Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 14:32 ` process-file and Tramp's file cache Stefan Monnier @ 2009-08-18 14:54 ` Michael Albinus 2009-08-18 16:23 ` Stefan Monnier 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2009-08-18 14:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: Julian Scheid, emacs-devel@gnu.org Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > How 'bout changing Tramp's process-file to compare the command (and > args) against a list of "known pure commands"? This would keep it all > inside Tramp, which I think I like better (tho I also agree that this > information is not fundamentally specific to Tramp, although currently > Tramp is the only package able to make use of it). That is also Julian's proposal. I dislike it, because there might be many packages Tramp has never heard about. And even for the packages contained in core Emacs, it will be an endless story: think about all the vc-BACKEND calls of list whatever. The charme is also, that packages can precisely say, which file has been changed. Tramp could only guess `t' or `nil'. Parsing `args' of `process-file' might also not a good idea, I believe. You cannot not know for sure, what is a filename, and what is something else. > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 14:54 ` Michael Albinus @ 2009-08-18 16:23 ` Stefan Monnier 2009-08-18 18:49 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2009-08-18 16:23 UTC (permalink / raw) To: Michael Albinus; +Cc: Julian Scheid, emacs-devel@gnu.org >> How 'bout changing Tramp's process-file to compare the command (and >> args) against a list of "known pure commands"? This would keep it all >> inside Tramp, which I think I like better (tho I also agree that this >> information is not fundamentally specific to Tramp, although currently >> Tramp is the only package able to make use of it). > That is also Julian's proposal. I dislike it, because there might be > many packages Tramp has never heard about. And even for the packages > contained in core Emacs, it will be an endless story: think about all the > vc-BACKEND calls of list whatever. OTOH, this list could be kept in a variable, so external packages could easily add to it. > The charme is also, that packages can precisely say, which file has been > changed. Clearly, each option has its advantages. I'd mostly like to avoid overengineering it, so for now I think a boolean is plenty (after all, we currently live fairly happily with a worst-case behavior). > Parsing `args' of `process-file' might also not a good idea, > I believe. It could prove problematic, indeed (I'm thinking mostly of having to search for "status" in the argument of "cvs", having to skip the options that might come before). Let's go with your suggestion, but limited to a boolean for now (so the name shouldn't end with "-list"). Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 16:23 ` Stefan Monnier @ 2009-08-18 18:49 ` Michael Albinus 2009-08-18 19:19 ` Stefan Monnier 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2009-08-18 18:49 UTC (permalink / raw) To: Stefan Monnier; +Cc: Julian Scheid, emacs-devel@gnu.org Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > Let's go with your suggestion, but limited to a boolean for now (so the > name shouldn't end with "-list"). Shouldn't it `process-file-modification-p' then? > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 18:49 ` Michael Albinus @ 2009-08-18 19:19 ` Stefan Monnier 2009-08-19 7:44 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Stefan Monnier @ 2009-08-18 19:19 UTC (permalink / raw) To: Michael Albinus; +Cc: Julian Scheid, emacs-devel@gnu.org >> Let's go with your suggestion, but limited to a boolean for now (so the >> name shouldn't end with "-list"). > Shouldn't it `process-file-modification-p' then? No: the "-p" is for functions returning booleans, not for variables. Note that "-flag" is not a good idea either, because it's incompatible with any future extension to additional values (e.g. a list of files). I suggest `process-file-side-effects'. Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: process-file and Tramp's file cache 2009-08-18 19:19 ` Stefan Monnier @ 2009-08-19 7:44 ` Michael Albinus 0 siblings, 0 replies; 7+ messages in thread From: Michael Albinus @ 2009-08-19 7:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: Julian Scheid, emacs-devel@gnu.org Stefan Monnier <monnier@iro.umontreal.ca> writes: > No: the "-p" is for functions returning booleans, not for variables. > Note that "-flag" is not a good idea either, because it's incompatible > with any future extension to additional values (e.g. a list of files). > I suggest `process-file-side-effects'. OK, we'll do so. When Julian's papers have arrived FSF, I'll commit it to the trunk (he has written most of the optimizations we're testing these days). > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-08-19 7:44 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87vdt2ndkt.fsf@tux.homenetwork> [not found] ` <200904071657.n37GvIau023055@godzilla.ics.uci.edu> [not found] ` <87d4bnfkxn.fsf@tux.homenetwork> [not found] ` <200904081624.n38GO6D6013154@godzilla.ics.uci.edu> [not found] ` <jwvbpr7c9sd.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <nq4owy7x5y.fsf@alcatel-lucent.de> [not found] ` <jwvy6u999m6.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <nqmyap7tpj.fsf@alcatel-lucent.de> [not found] ` <jwvy6u97kqn.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <87myalrb5w.fsf@gmx.de> [not found] ` <jwv1vrxzmoz.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <87r5zxprx9.fsf@gmx.de> [not found] ` <jwv8wm5xzqq.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <87prfgzys9.fsf@gmx.de> [not found] ` <jwvprfgwxmp.fsf-monnier+emacsbugreports@gnu.org> [not found] ` <nqtz4ruut9.fsf@alcatel-lucent.de> [not found] ` <jwveivvrww9.fsf-monnier+emacsbugreports@gnu.org> 2009-08-18 10:16 ` process-file and Tramp's file cache (was: bug#1741: 23.0.60; vc fail to register file while logged as /su:: with tramp) Michael Albinus 2009-08-18 14:32 ` process-file and Tramp's file cache Stefan Monnier 2009-08-18 14:54 ` Michael Albinus 2009-08-18 16:23 ` Stefan Monnier 2009-08-18 18:49 ` Michael Albinus 2009-08-18 19:19 ` Stefan Monnier 2009-08-19 7:44 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).