unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* RE: vc-state always calls heuristic function
@ 2004-11-24  8:39 klaus.berndl
  2004-11-24 10:55 ` Andre Spiegel
  2004-11-24 13:54 ` Stefan Monnier
  0 siblings, 2 replies; 14+ messages in thread
From: klaus.berndl @ 2004-11-24  8:39 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-12-03  7:32 klaus.berndl
  0 siblings, 0 replies; 14+ messages in thread
From: klaus.berndl @ 2004-12-03  7:32 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-11-24 14:44 klaus.berndl
  0 siblings, 0 replies; 14+ messages in thread
From: klaus.berndl @ 2004-11-24 14:44 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-11-24 12:11 klaus.berndl
  0 siblings, 0 replies; 14+ messages in thread
From: klaus.berndl @ 2004-11-24 12:11 UTC (permalink / raw)
  Cc: monnier, emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-11-24 11:08 klaus.berndl
  0 siblings, 0 replies; 14+ messages in thread
From: klaus.berndl @ 2004-11-24 11:08 UTC (permalink / raw)
  Cc: monnier, emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-11-24 11:04 klaus.berndl
  2004-11-24 12:00 ` Andre Spiegel
  0 siblings, 1 reply; 14+ messages in thread
From: klaus.berndl @ 2004-11-24 11:04 UTC (permalink / raw)
  Cc: monnier, emacs-devel

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: vc-state always calls heuristic function
@ 2004-11-23 17:31 klaus.berndl
  2004-11-23 20:44 ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: klaus.berndl @ 2004-11-23 17:31 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* vc-state always calls heuristic function
@ 2004-11-23 16:57 klaus.berndl
  2004-11-23 17:21 ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: klaus.berndl @ 2004-11-23 16:57 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2004-12-03  7:32 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-24  8:39 vc-state always calls heuristic function klaus.berndl
2004-11-24 10:55 ` Andre Spiegel
2004-11-24 13:54 ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2004-12-03  7:32 klaus.berndl
2004-11-24 14:44 klaus.berndl
2004-11-24 12:11 klaus.berndl
2004-11-24 11:08 klaus.berndl
2004-11-24 11:04 klaus.berndl
2004-11-24 12:00 ` Andre Spiegel
2004-11-23 17:31 klaus.berndl
2004-11-23 20:44 ` Stefan Monnier
2004-12-02 19:19   ` Kevin Rodgers
2004-11-23 16:57 klaus.berndl
2004-11-23 17:21 ` Stefan Monnier

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).