From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Idea for determining what users use Date: Sat, 31 May 2003 08:37:03 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: Reply-To: ttn@glug.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1054384583 3995 80.91.224.249 (31 May 2003 12:36:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 31 May 2003 12:36:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 31 14:36:21 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19M5av-000127-00 for ; Sat, 31 May 2003 14:36:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19M5qZ-0003DC-00 for ; Sat, 31 May 2003 14:52:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19M5c6-00070h-EZ for emacs-devel@quimby.gnus.org; Sat, 31 May 2003 08:37:34 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19M5bf-0006s7-Rc for emacs-devel@gnu.org; Sat, 31 May 2003 08:37:07 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19M5bd-0006lm-Kj for emacs-devel@gnu.org; Sat, 31 May 2003 08:37:06 -0400 Original-Received: from colo.agora-net.com ([207.245.84.69]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19M5bb-0006hn-J9; Sat, 31 May 2003 08:37:03 -0400 Original-Received: from ttn by colo.agora-net.com with local (Exim 3.34 #1) id 19M5bb-0001dL-00; Sat, 31 May 2003 08:37:03 -0400 Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Thu, 29 May 2003 20:48:58 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14517 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14517 From: Richard Stallman Date: Thu, 29 May 2003 20:48:58 -0400 We could try to make it useful to other programmers--I have nothing against trying. But not in a way that interferes with the original intended purpose, which is use for us. certainly. it sounds like the requirements for us are that we get extremely compacted information (1-bit per feature) associated w/ a particular release. For others to be able to use this, they need to be able to specify the email address in the call. That won't be hard. agreed. whether one hit or multiple hits, IMHO it is better to separate the collection and reporting sub-activities, not only for efficiency but also to support user control/privacy. I don't see how this could possibly make sense, but if you show me a specific alternative scenario, I will think about whether it is better. sorry, i should have used the word "features" instead of "hits". in our case, for any feature, it is desirable to get only one bit of info (that it is, whether the feature is indeed being used). also, the number of features is likely to be small. for the more general instrumentation i'm slowly fulminating (since the design of spyware is not the most happy activity, but i feel if it must be done, might as well do a good job and include proper warnings and explanations), there may be more bits involved along w/ more complicated collection methods, some requiring repeated sampling. an example of this would be, in hideshow.el, to answer the question "how often does hs-headline usage lose due to C-g?". i would need to collect (repeatedly) hs-headline usage info along w/ "fixing the lossage" info, represented in part by back-to-back invocations of M-x hs-minor-mode (see Commentary). to do this i would add something like: (snitch-collect-incf '(hideshow using-hs-headline)) to those places where hs-headline is set, and (when (eq 'hs-minor-mode last-command) (snitch-collect-incf '(hideshow back-to-back-hs-minor-mode))) to hs-minor-mode. `snitch-collect-incf' is a specialization of the general `snitch-assoc-apply' (access $USER-snitched assoc list, munge as needed, in this case incrementing a counter). anyway, given this base, we can do something like: (defun note-used-feature (name description) (snitch-assoc-apply name (lambda (current) (unless current ; one-shot (compose-mail *feature-assay-email-address* (format "%s: %s" emacs-version description) ...) ;; retval is stashed in $USER-snitched t)))) disclaimer: i don't actually intend to use snitch for official hideshow.el maintenance in this way, but such a facility would be nice for prereleases and other unofficial stuff. to be annoyingly redundant, IMHO the compose-mail call should be moved to a second-phase; the example above is solely to demonstrate conformance to your original design requirements. like any code, its frequency of use is really up to its users once it gets into the wild. The purpose of this feature is for us to use it for low-frequency messages. There is no sense in redesigning it to optimize for some other scenario at the expense of the intended purpose. well i hope the design i have sketched is supportive of both our needs and other needs. i haven't thought too much on whether or not it is optimized for one or the other in particular. the main thing i like to optimize for is effort (reducing it over the long run ;-). If you have some other application in mind and this feature isn't good for your application, then design some other feature. ok, will check in a snitch.el independently at some point. thanks for triggering these interesting thoughts w/ your idea. thi