RE: vc-state always calls heuristic function

RE: vc-state always calls heuristic function

[klaus.berndl]

Stefan Monnier wrote:
>> The next version of ECB (Emacs Code browser) will display the
>> VC-state 
>> of sourcefiles with image-icons in its special browsable
>> tree-windows. 
>> For this a function is needed to compute the VC-state of a file.
>> Whic one 
>> is used is customizable in an option of ECB - and currently
>> `vc-state' is used per default for the backend CVS, RCS and SCCS...
>> and i have wondered 
>> if there is a function available which performs real checks not only
>> heuristic - now i know such a function - thanks Stefan!
>> I think i will not use vc-recompute-state per default because
>> especially with remote repositories this can be very expensive -
>> even the state-check is performed stealthy and interruptable in the
>> background as with ECB. 
> 
> It's only interruptible with C-g, right?  I don't call that very
> "stealth" if it forces me to hit C-g (or to wait for tens of seconds).

I agree - this i wouldn't call interruptable and stealth too ;-) But in fact the
stealth-mechanism of ECB allows running arbitrary tasks when Emacs is
idle (customizable delay) and all are interruptable by any keypress or
mouse-action...

I do this via (simplified):

            (while (and (not (input-pending-p))

means a stealthy task (e.g. checking the VC-state for a set of currently
displayed files in the file-browser of ECB) process this set in a while-loop
and between each pass of the loop it is interruptable..well, but of course there
remains the problem - how to interrupt if one pass takes long time...
here i have currently no real good idea how to interrupt that (unless using
C-g)...of course a potential expensive task line the VC-check could be implementes
via asynchron cvs-calls (start-process etc...) but then i can not use the VC-code
and moreover it would be qute compilcated to implement this... So if you have a
good idea..... ;-)

Do you call this stealth?

> 
>> But i want to mentionin the docstring of that ECB-option that there
>> is another function `vc-recompute-state' a user can use if he works
>> in a fast LAN and with a CVS-server in that LAN for example....
> 
>> understandable?
> 
> Yes.
> Please don't.  `vc-recompute-state' is an internal function, don't
> touch it, don't use it.
> There's vc-cvs-stay-local, it's customizable, it does what you want.
> Don't use vc-cvs-stay-local (of course): just tell your users that if
> they want fresh-but-slow state, they can tweak that variable.

Hmm, now i'm confused... ECB needs a function how to get the VC-state. Well,
the user can customize which function ECB should use. But if he should
not use `vc-recompute-state' how he should get fresh-but-slow state??
If only vc-state is used then tweaking vc-cvs-stay-local wil never take
effect but vc-state always call the heursitic backend-function (and
vc-cvs-state-heuristic also never uses vc-cvs-stay-local)... Would it better
to use the backend function itself - so vc-cvs-state when a user wants fresh
state (ECB allows to specify different "get-state"-functions for different
backends...)??

Klaus

> 
> 
>         Stefan

RE: vc-state always calls heuristic function

[Andre Spiegel]

On Wed, 2004-11-24 at 09:39 +0100, klaus.berndl@sdm.de wrote:

> Hmm, now i'm confused... ECB needs a function how to get the VC-state. Well,
> the user can customize which function ECB should use. But if he should
> not use `vc-recompute-state' how he should get fresh-but-slow state??
> If only vc-state is used then tweaking vc-cvs-stay-local wil never take
> effect but vc-state always call the heursitic backend-function (and
> vc-cvs-state-heuristic also never uses vc-cvs-stay-local)... Would it better
> to use the backend function itself - so vc-cvs-state when a user wants fresh
> state (ECB allows to specify different "get-state"-functions for different
> backends...)??

VC/CVS actually does it this way:  When you visit a file, it always uses
just the heuristic to get the state (comparing file times), regardless
of the setting of vc-cvs-stay-local.  This is because the
"fresh-but-slow" state is determined by calling "cvs status" on the
file, and this was deemed unacceptably slow if done at visiting time
under any conditions.

The state is updated by calling vc-recompute-state prior to
vc-next-action (C-x v v).  IF vc-cvs-stay-local is nil, then this does
in fact call "cvs status" to get the "fresh-but-slow-state", but if
vc-cvs-stay-local is t, then it just compares the file times again.

The bottom line for you is this: If you use vc-state to get the version
control state, then you get the same policy that VC uses.  I don't see
any harm if you let people use vc-recompute-state as a replacement
function, but then (a) people must make sure to set vc-cvs-stay-local to
nil, and (b) fetching the state over the network under all conditions
was deemed unacceptably slow in VC, and perhaps it's the same for your
problem as well.

You should NEVER call vc-cvs-state or vc-cvs-state-heuristic directly
however, because that would mess up VC's caching of these values in the
vc-state property.

All things considered, I'd say stick with the vc-state function, and
educate your users how to tweak its behaviour via vc-cvs-stay-local.

Re: vc-state always calls heuristic function

[Stefan Monnier]

> and between each pass of the loop it is interruptable..well, but of course
> there remains the problem - how to interrupt if one pass takes long
> time...

Google for `while-no-input'.

> Hmm, now i'm confused... ECB needs a function how to get the VC-state. Well,
> the user can customize which function ECB should use.  But if he should
> not use `vc-recompute-state' how he should get fresh-but-slow state??

Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
attention to vc-cvs-stay-local.  Hmmm....
I guess VC could/should provide a function like vc-recompute-state or
vc-check-for-updates.  Currently this operation is only provided as part of
vc-next-action, but it might be nice to decouple the two.


        Stefan

RE: vc-state always calls heuristic function

[klaus.berndl]

Kevin Rodgers wrote:
> Stefan Monnier wrote:
>  > There's vc-cvs-stay-local, it's customizable, it does what you
>  want. > Don't use vc-cvs-stay-local (of course): just tell your
> users that if they
>  > want fresh-but-slow state, they can tweak that variable.
> 
> What would be wrong with ECB doing
> 
> (let ((vc-cvs-stay-local nil))
>    (vc-state FILE))

vc-cvs-stay-local does not infect vc-state - vc-state calls always(!)
vc-cvs-state-heuristic (in case of CVS) and this function doesn
not use this variable!

Only vc-recompute-state (and the delegation to vc-cvs-state) use it..

Klaus

RE: vc-state always calls heuristic function

[klaus.berndl]

Stefan Monnier wrote:
>> and between each pass of the loop it is interruptable..well, but of
>> course there remains the problem - how to interrupt if one pass
>> takes long 
>> time...
> 
> Google for `while-no-input'.

Done - after reading the whole thread i can say: I agree at 100% with you and Kim.
Such a macro would be very important especially for a program like Emacs which
has still not thread-feature like Java, C++ et. al. IMHO this is one of the
most important any annoying lacks of emacs-lisp and for programmers...
And i agree with Kim that especially people working with remote-paths and
packages which makes this completely transparent (like tramp, ange-ftp and efs)
would profite a lot from such a macro like while-no-input - 

The current discussion how to enable tools like ECB to display some state-value
for files (as the VC-state-values) where the computation could be expensive
is IMHO a good example to demonstrate the need of such feature - so we have no
threads avaliable in emacs-lisp to perform such expensive tasks in the background
without blocking the user of Emacs but we could at least offer the users of
such tools a way how to easily (hitting C-g is not acceptable) interrupt also
"atomic" calls as call of call-process etc...

Well, Stefan - this thread was discussed in 2002 - what is current state of
this while-no-input???

>> Hmm, now i'm confused... ECB needs a function how to get the
>> VC-state. Well, the user can customize which function ECB should
>> use.  But if he should 
>> not use `vc-recompute-state' how he should get fresh-but-slow state??
> 
> Oh, you're right I got confused: vc-cvs-heuristic-state doesn't pay
> attention to vc-cvs-stay-local.  Hmmm....
> I guess VC could/should provide a function like vc-recompute-state or
> vc-check-for-updates.  Currently this operation is only provided as
> part of vc-next-action, but it might be nice to decouple the two.

Yes, see my discussion with Andre about this...

Klaus

> 
> 
>         Stefan

RE: vc-state always calls heuristic function

[klaus.berndl]

Andre Spiegel wrote:
> On Wed, 2004-11-24 at 12:04 +0100, klaus.berndl@sdm.de wrote:
> 
>> If i have understood you right - there is currently no really
>> acceptable way (concering performance) to display in a file-browser
>> icons which always reflect the real (not heuristic) state of a file,
>> right?
> 
> The only way to get this information is to call "cvs status", and that
> is indeed unacceptably slow if you do it for every display update.
> There might be a clever shortcut looking at the RCS master files if
> the repository is local, but we never thought it was worth the
> trouble. 

I agree... but i have tested calling vc-recompute-state (vc-cvs-stay-local nil)
with local repositories - IMHO this is acceptable fast - but 
unfortunatelly real local repositories will be seldom - at least in 
real projects i assume - and running vc-recompute-state against
a repository in a LAN-network (an often case i think) is surely faster
then ageianst a remote-repository like at Sourceforge but probably
still to slow...for displaying the state in a file-browser...

> 
> If you decide that vc-recompute-state would suit your needs after all
> (and your case is convincing :-) then please let me know and we can
> place it into vc-hooks.el (or autoload it).

IMHO it would be good if vc-recompute-state could be made an "official"
interface for packages which are interested in the VC-state of certain
files - IMHO vc-state and vc-recompute-state should have the same
specification and should be alternatives... This would great!

Then ECB (or the user of ECB :-) could decide if the access to its
repositories is fast enough to use `vc-recompute-state' with tha advantage
getting always the correct VC-state being display in the file-browser
of ECB or not (then vc-state will fit his needs...)

Thoughts?

Ciao
Klaus

RE: vc-state always calls heuristic function

[klaus.berndl]

klaus.berndl@sdm.de wrote:
> Thanks a lot for this detailed explanation, Andre!!
> No i understand...
    ^
Typo...Must be "Now" instead of "No" ! ;-)

> 
> If i have understood you right - there is currently no really
> acceptable way (concering performance) to display in a file-browser
> icons which always reflect the real (not heuristic) state of a file,
> right?
> 
> Ciao,
> Klaus
> 
> Andre Spiegel wrote:
>> On Wed, 2004-11-24 at 09:39 +0100, klaus.berndl@sdm.de wrote:
>> 
>>> Hmm, now i'm confused... ECB needs a function how to get the
>>> VC-state. Well, the user can customize which function ECB should
>>> use. But if he should not use `vc-recompute-state' how he should
>>> get fresh-but-slow state?? If only vc-state is used then tweaking
>>> vc-cvs-stay-local wil never take effect but vc-state always call
>>> the heursitic backend-function (and vc-cvs-state-heuristic also
>>> never uses vc-cvs-stay-local)... Would it better to use the backend
>>> function itself - so vc-cvs-state when a user wants fresh state
>>> (ECB allows to specify different "get-state"-functions for
>>> different backends...)?? 
>> 
>> VC/CVS actually does it this way:  When you visit a file, it always
>> uses just the heuristic to get the state (comparing file times),
>> regardless of the setting of vc-cvs-stay-local.  This is because the
>> "fresh-but-slow" state is determined by calling "cvs status" on the
>> file, and this was deemed unacceptably slow if done at visiting time
>> under any conditions. 
>> 
>> The state is updated by calling vc-recompute-state prior to
>> vc-next-action (C-x v v).  IF vc-cvs-stay-local is nil, then this
>> does in fact call "cvs status" to get the "fresh-but-slow-state",
>> but if vc-cvs-stay-local is t, then it just compares the file times
>> again. 
>> 
>> The bottom line for you is this: If you use vc-state to get the
>> version control state, then you get the same policy that VC uses.  I
>> don't see any harm if you let people use vc-recompute-state as a
>> replacement function, but then (a) people must make sure to set
>> vc-cvs-stay-local to nil, and (b) fetching the state over the network
>> under all conditions was deemed unacceptably slow in VC, and perhaps
>> it's the same for your problem as well.
>> 
>> You should NEVER call vc-cvs-state or vc-cvs-state-heuristic directly
>> however, because that would mess up VC's caching of these values in
>> the vc-state property. 
>> 
>> All things considered, I'd say stick with the vc-state function, and
>> educate your users how to tweak its behaviour via vc-cvs-stay-local.
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: vc-state always calls heuristic function

[klaus.berndl]

Thanks a lot for this detailed explanation, Andre!!
No i understand...

If i have understood you right - there is currently no really
acceptable way (concering performance) to display in a file-browser
icons which always reflect the real (not heuristic) state of a file,
right?

Ciao,
Klaus

Andre Spiegel wrote:
> On Wed, 2004-11-24 at 09:39 +0100, klaus.berndl@sdm.de wrote:
> 
>> Hmm, now i'm confused... ECB needs a function how to get the
>> VC-state. Well, the user can customize which function ECB should
>> use. But if he should 
>> not use `vc-recompute-state' how he should get fresh-but-slow state??
>> If only vc-state is used then tweaking vc-cvs-stay-local wil never
>> take effect but vc-state always call the heursitic backend-function
>> (and vc-cvs-state-heuristic also never uses vc-cvs-stay-local)...
>> Would it better to use the backend function itself - so vc-cvs-state
>> when a user wants fresh state (ECB allows to specify different
>> "get-state"-functions for different backends...)??
> 
> VC/CVS actually does it this way:  When you visit a file, it always
> uses just the heuristic to get the state (comparing file times),
> regardless of the setting of vc-cvs-stay-local.  This is because the
> "fresh-but-slow" state is determined by calling "cvs status" on the
> file, and this was deemed unacceptably slow if done at visiting time
> under any conditions.
> 
> The state is updated by calling vc-recompute-state prior to
> vc-next-action (C-x v v).  IF vc-cvs-stay-local is nil, then this does
> in fact call "cvs status" to get the "fresh-but-slow-state", but if
> vc-cvs-stay-local is t, then it just compares the file times again.
> 
> The bottom line for you is this: If you use vc-state to get the
> version control state, then you get the same policy that VC uses.  I
> don't see any harm if you let people use vc-recompute-state as a
> replacement function, but then (a) people must make sure to set
> vc-cvs-stay-local to nil, and (b) fetching the state over the network
> under all conditions was deemed unacceptably slow in VC, and perhaps
> it's the same for your problem as well.
> 
> You should NEVER call vc-cvs-state or vc-cvs-state-heuristic directly
> however, because that would mess up VC's caching of these values in
> the vc-state property.
> 
> All things considered, I'd say stick with the vc-state function, and
> educate your users how to tweak its behaviour via vc-cvs-stay-local.

RE: vc-state always calls heuristic function

[Andre Spiegel]

On Wed, 2004-11-24 at 12:04 +0100, klaus.berndl@sdm.de wrote:

> If i have understood you right - there is currently no really
> acceptable way (concering performance) to display in a file-browser
> icons which always reflect the real (not heuristic) state of a file,
> right?

The only way to get this information is to call "cvs status", and that
is indeed unacceptably slow if you do it for every display update.
There might be a clever shortcut looking at the RCS master files if the
repository is local, but we never thought it was worth the trouble.

If you decide that vc-recompute-state would suit your needs after all
(and your case is convincing :-) then please let me know and we can
place it into vc-hooks.el (or autoload it).

RE: vc-state always calls heuristic function

[klaus.berndl]

Stefan Monnier wrote:
>> You see, that always the heuristic method of a backend is used
>> [(vc-call state-heuristic file)] - even if a backend offers also
>> a "real" statechecker. E.g. vc-cvs.el offers `vc-cvs-state' and
>> `vc-cvs-state-heuristic'... But current implementation of `vc-state'
>> will never use `vc-cvs-state'! Why??
> 
> Why not?
> 
>> IMHO there should be a way so a user can customize if `vc-state'
>> should use the heuristic approach or the real state-check if a
>> backend offers both of them. What do you think?
> 
> It's the responsability of the backend.
> vc.el uses `state-heuristic' when a heuristic is enough (e.g. in
> vc-state) and uses `state' when it really needs fresh data (in
> `vc-recompute-state'). 

ah, i didn't know the function `vc-recompute-state' - my fault..

> 
> The backend is then free to always use fresh data, or to use a
> heuristic when possible.  Backends usually use a config var such as
> vc-cvs-stay-local to decide which to choose.
> 
> What problem are you trying to solve?

The next version of ECB (Emacs Code browser) will display the VC-state
of sourcefiles with image-icons in its special browsable tree-windows.
For this a function is needed to compute the VC-state of a file. Whic one
is used is customizable in an option of ECB - and currently `vc-state' is
used per default for the backend CVS, RCS and SCCS... and i have wondered
if there is a function available which performs real checks not only
heuristic - now i know such a function - thanks Stefan!
I think i will not use vc-recompute-state per default because especially with
remote repositories this can be very expensive - even the state-check is 
performed stealthy and interruptable in the background as with ECB.
But i want to mentionin the docstring of that ECB-option that there
is another function `vc-recompute-state' a user can use if he works
in a fast LAN and with a CVS-server in that LAN for example....

understandable?

Ciao,
Klaus



> 
> 
>         Stefan

Re: vc-state always calls heuristic function

[Stefan Monnier]

> The next version of ECB (Emacs Code browser) will display the VC-state
> of sourcefiles with image-icons in its special browsable tree-windows.
> For this a function is needed to compute the VC-state of a file. Whic one
> is used is customizable in an option of ECB - and currently `vc-state' is
> used per default for the backend CVS, RCS and SCCS... and i have wondered
> if there is a function available which performs real checks not only
> heuristic - now i know such a function - thanks Stefan!
> I think i will not use vc-recompute-state per default because especially with
> remote repositories this can be very expensive - even the state-check is 
> performed stealthy and interruptable in the background as with ECB.

It's only interruptible with C-g, right?  I don't call that very "stealth"
if it forces me to hit C-g (or to wait for tens of seconds).

> But i want to mentionin the docstring of that ECB-option that there
> is another function `vc-recompute-state' a user can use if he works
> in a fast LAN and with a CVS-server in that LAN for example....

> understandable?

Yes.
Please don't.  `vc-recompute-state' is an internal function, don't touch it,
don't use it.
There's vc-cvs-stay-local, it's customizable, it does what you want.
Don't use vc-cvs-stay-local (of course): just tell your users that if they
want fresh-but-slow state, they can tweak that variable.


        Stefan

Re: vc-state always calls heuristic function

[Kevin Rodgers]

Stefan Monnier wrote:
 > There's vc-cvs-stay-local, it's customizable, it does what you want.
 > Don't use vc-cvs-stay-local (of course): just tell your users that if 
they
 > want fresh-but-slow state, they can tweak that variable.

What would be wrong with ECB doing

(let ((vc-cvs-stay-local nil))
   (vc-state FILE))

-- 
Kevin Rodgers

vc-state always calls heuristic function

[klaus.berndl]

This is the current implementation of the vc-state-function:

(defun vc-state (file)
  "Return the version control state of FILE.
  ..."
  ;; FIXME: New (sub)states needed (?):
  ;; - `added' (i.e. `edited' but with no base version yet,
  ;;            typically represented by vc-workfile-version = "0")
  ;; - `conflict' (i.e. `edited' with conflict markers)
  ;; - `removed'
  ;; - `copied' and `moved' (might be handled by `removed' and `added')
  (or (vc-file-getprop file 'vc-state)
      (if (vc-backend file)
          (vc-file-setprop file 'vc-state
                           (vc-call state-heuristic file)))))

You see, that always the heuristic method of a backend is used
[(vc-call state-heuristic file)] - even if a backend offers also
a "real" statechecker. E.g. vc-cvs.el offers `vc-cvs-state' and
`vc-cvs-state-heuristic'... But current implementation of `vc-state'
will never use `vc-cvs-state'! Why??

IMHO there should be a way so a user can customize if `vc-state' should
use the heuristic approach or the real state-check if a backend offers
both of them. What do you think?

Ciao,
Klaus

Klaus Berndl                     mailto: klaus.berndl@sdm.de
sd&m AG                         http://www.sdm.de
software design & management
Carl-Wery-Str. 42, 81739 Muenchen, Germany
Tel +49 89 63812-392, Fax -220

Re: vc-state always calls heuristic function

[Stefan Monnier]

> You see, that always the heuristic method of a backend is used
> [(vc-call state-heuristic file)] - even if a backend offers also
> a "real" statechecker. E.g. vc-cvs.el offers `vc-cvs-state' and
> `vc-cvs-state-heuristic'... But current implementation of `vc-state'
> will never use `vc-cvs-state'! Why??

Why not?

> IMHO there should be a way so a user can customize if `vc-state' should
> use the heuristic approach or the real state-check if a backend offers
> both of them. What do you think?

It's the responsability of the backend.
vc.el uses `state-heuristic' when a heuristic is enough (e.g. in vc-state)
and uses `state' when it really needs fresh data (in `vc-recompute-state').

The backend is then free to always use fresh data, or to use a heuristic
when possible.  Backends usually use a config var such as vc-cvs-stay-local
to decide which to choose.

What problem are you trying to solve?


        Stefan