From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: Back to emacsclient/server Date: Sat, 28 Oct 2006 23:16:29 +0200 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1162070212 9972 80.91.229.2 (28 Oct 2006 21:16:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 28 Oct 2006 21:16:52 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 28 23:16:51 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GdvXr-0004au-Fq for ged-emacs-devel@m.gmane.org; Sat, 28 Oct 2006 23:16:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GdvXq-0005Dt-P1 for ged-emacs-devel@m.gmane.org; Sat, 28 Oct 2006 17:16:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GdvXd-0005C5-GB for emacs-devel@gnu.org; Sat, 28 Oct 2006 17:16:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GdvXb-00059v-5U for emacs-devel@gnu.org; Sat, 28 Oct 2006 17:16:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GdvXa-00059Z-Vp for emacs-devel@gnu.org; Sat, 28 Oct 2006 17:16:31 -0400 Original-Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GdvXa-0006fk-PM for emacs-devel@gnu.org; Sat, 28 Oct 2006 17:16:30 -0400 Original-Received: by nf-out-0910.google.com with SMTP id q29so1973931nfc for ; Sat, 28 Oct 2006 14:16:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CXI2iMVMVnJMKbV/an01bZw02TXxIRAqesJwjcJHvk4eWYh7/hZMmYlauNLclp4MZwsLSpz/5rWYNL1MX9nPtspxn8VS3E5IRCuqMX0wtfezNQSUH3RIQW85HRsg+JEF59FPRnPK3uKk/IAFr/xF31/s9t5dz6swSGXq+1v7Bhk= Original-Received: by 10.82.135.13 with SMTP id i13mr181882bud; Sat, 28 Oct 2006 14:16:29 -0700 (PDT) Original-Received: by 10.82.136.11 with HTTP; Sat, 28 Oct 2006 14:16:29 -0700 (PDT) Original-To: emacs-devel@gnu.org In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:61312 Archived-At: On 10/28/06, Richard Stallman wrote: > Let's make (random 'random) generate a new seed, use it, then restore > the old one, so that it has no effect on the sequence. This is a much > smaller change than adding a means to read and set the random seed. On one hand, both are really equivalent. To restore the old seed you first need a way to get it. The current random code in sysdep.c tries to massage wildly different random implementations (lrand48, rand, etc.) into a consistent interface, and there's no support in place *at all* for getting back the seed (which also varies quite a lot across implementations of random functions). I don't think is very sensible to hastily add now a mechanism for getting the seed which, to make any sense, should have to be heavily tested in as much environments as possible. On the other hand, I don't quite get what you're proposing. Currently, the output of (random t) is almost never used, because when you're passing t you cannot pass N. In the Emacs sources, (random) is used about 7 times, while (random N) is used approx. 70. But your proposed (random 'random), if I'm understanding you, would save the seed, return a value, then restore the seed. For that to be useful, it'd have to be (random N 'random). Moreover, the current `random', when passed t, does: seed_random (getpid () + time (NULL)); So in many situations, when several values are needed at once (as is the case in server.el), the code using your 'random would be: loop N times save seed set seed to (getpid () + time (NULL)) collect a random value restore seed end loop I very much doubt the result is hardly random enough; in fact, getpid() + time(NULL) is bound to return the same value for a lot of consecutive calls... To make that useful we'd need a way to get N values at once from random. But I think that's all unnecessary right now. As others have pointed out, several packages already do initialize the random seed for trivial reasons; I see no harm in doing the same in server.el. If your proposal (or any variant) is ever implemented, fixing server.el is a one-line change. /L/e/k/t/u