From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18507 invoked from network); 23 Nov 2022 21:44:24 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2022 21:44:24 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1669239864; b=kX0I0XoJC/d34ckjRb86t1tEGW1a+EMn8AzC3Pm0mD6j36OOlltUogLmB+YD29kkETH3Jp7pTs BUazhjk7/71sZDjawTxlivehj7ZkRGdBWIFLMfXVQJSPJlO8TmzMJMYimZJ/wNDjYe8hTJN6RM AMkEgudMExtBaA1fqxYyLAW8cfNLwK0Hz+X4Sqyt9Rcg0HPsgr1dxacDyDKUvlQVIkRjbx50zU PuSlpKPBWCJfjOpq6UoBzrnOeoPR7wz23O++/LGYBemhxJvk8TbGNlvakAAJBHW+nZYiI50qwx TU4YISBI2aBqg76GhK42diAcOcuzt0cc81tKY8JgdsMIew==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (out1-smtp.messagingengine.com) smtp.remote-ip=66.111.4.25; dkim=pass header.d=dana.is header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=dana.is; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1669239864; bh=4DA2zIvagiQ6x2rlVKE5tR23qU2P9CBk1ZZXgYqR5Es=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:Subject:Cc:To:From: Date:References:In-Reply-To:Message-ID:MIME-Version:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=WbeDQX06B0UO1OEzluxqmcAbBQhsBa82xKHRwVV/jK0SA9SLBRQfvWlqSebzedMa1f6IvxefLa /H/zwuDCdx3FaPBdmMgNJ5qZan/Lv48baaQSMfqmLykiUm7HkI8ZZxZZInaq520CQ6z3+6jnhD Oy01bRn2LxUTV2lOjstOH6kLRnjq1huGerD/ipj6sHYvrSP0kyXqiigOJnXFk5lLli7O6O5E4z UBeOievtOvF57ayMhTwkVg3R8dpupCaB/JRymBxbV5BFCwbi+ASLP//ikcl570OLgwt7iuLXIw XmQNIkJMHq/al1LeXFMO6saXjZhscqyCY0j5AOghj200LQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Transfer-Encoding: Content-Type:Subject:Cc:To:From:Date:References:In-Reply-To:Message-Id: Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=xn/G3S7riUB0h7tHQmwNCYM3bvh4olfjhrnN1PcWhog=; b=GePm/8YWjxG0iRln42eTp82vFs Fv/mf758bZu0HNg4bpsCtCLiRxyp8Iy3GFjeAnGI9Zp2hL3RvuFiUKUbTa8lGgb/vdpClv08G9Gad UZVEER9WkmcffVkQuXUKDVjVRazX/IhB6HyO/F71HEJ2fYgHwNvMvdThVlYlR79eKTgf31GfCIwkY 174Ln3qAw0hZ8fHqcSsANFrZXfzyOWmvF/GIsqz/lkltX4en3oRJ189QWXOnw3uoffKAgZ6YiGmnz GxmHh4BwQyDtOk8IiRXSNj8vPfHwA7pqj2Qp5lzFX/iWtc/hGlrYWKn7/nqfQbo4bByVLvHx+mCJO 91uW0+3w==; Received: by zero.zsh.org with local id 1oxxXc-00024F-PT; Wed, 23 Nov 2022 21:44:24 +0000 Authentication-Results: zsh.org; iprev=pass (out1-smtp.messagingengine.com) smtp.remote-ip=66.111.4.25; dkim=pass header.d=dana.is header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=dana.is; arc=none Received: from out1-smtp.messagingengine.com ([66.111.4.25]:49449) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1oxxXJ-0001il-9Z; Wed, 23 Nov 2022 21:44:07 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 926A65C012F; Wed, 23 Nov 2022 16:44:04 -0500 (EST) Received: from imap50 ([10.202.2.100]) by compute5.internal (MEProxy); Wed, 23 Nov 2022 16:44:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dana.is; h=cc:cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1669239844; x= 1669326244; bh=xn/G3S7riUB0h7tHQmwNCYM3bvh4olfjhrnN1PcWhog=; b=V DwEPYzqA1y1fjzUM/ZGwgcRTOVWcj8QnWbKX+YoJIOqp9aWNvOKMPAp+oTQQSL4a 2Y/C2iAPNJ0ffZ3SJDI/36PEFO3wk5+s2Tu3NAoYrk3tdCk7Xu2Voz9MTDM6A06r zndqis88FTCkEvptWlXfBs8LqyA78Ae+qMT55ePrx0PnYfBWMak5Hw6mdgM78PlQ ihRqNrlUlCXLnr/EOv0E/MKqpgtakrru9NCVJTGDqyoRB8O/p815PXawitNAeJTW lw+EO9rGAY9k232mOFx45MP427BSVg+TerdJ4vLla3GbZECQCk3DcXrRMb7nZ8Vb 7vCtTCoj1zR5YJn1cwQjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1669239844; x= 1669326244; bh=xn/G3S7riUB0h7tHQmwNCYM3bvh4olfjhrnN1PcWhog=; b=L iYk2N40NxxRJ74nj/lL/AoAXv6v0NOuCMSHBYT+WezHzMt1lwQ3Y16hd5iXXmEVs rU0iZNXk8ndskwjKw7lh0k/NGq8KNogXwI28lG+z76WcCKiD/r/3P3+0Jk9/n/6p 3nQsus+ctF7SEHEbPF+iHzC6TK+pgyCAzu1DMt+3ZU3FeiHhlL9yreZkDb1lNBlL u2g3s2LnI5dy5AFJziJ/F0vyJEVD08T52i/xylqbg5M0rSn1xzeys96UcXg8Grrf D9WYXAGAXtPZSngaK80+iMNNkj8EnK/Ms8oEKVDdsnk7QlygtycnBi+wRHiqc2BD +TcFCPbEhHsy8nSdIy+lQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedriedugddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgfgse htqhertderreejnecuhfhrohhmpegurghnrgcuoegurghnrgesuggrnhgrrdhisheqnecu ggftrfgrthhtvghrnheptedvkeffueetieevveekfffhtdegudeuudeigfefgfeukedtgf dtffehfeeuhfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepuggrnhgrsegurghnrgdrihhs X-ME-Proxy: Feedback-ID: i9be146f9:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21DEE1700090; Wed, 23 Nov 2022 16:44:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <869f6d65-15d2-477f-b78b-02427a0c1395@app.fastmail.com> In-Reply-To: <20221123203329.GP27622@tarpaulin.shahaf.local2> References: <1b2cafe6-b4b5-c59a-11f3-4dbc1e99e2bc@zentaur.org> <6275a5ac-3a47-f591-7b3c-380ec4fed5ac@zentaur.org> <3423b634-a7c3-9efc-92cd-b9b995ac1c27@zentaur.org> <30a7e749-7f30-ecae-6479-a345b1682e7f@zentaur.org> <2df1001e-69a6-9785-70a6-8416fdcffd8d@zentaur.org> <0a07afaf-1194-6752-8133-8aa6b689724d@zentaur.org> <20221123203329.GP27622@tarpaulin.shahaf.local2> Date: Wed, 23 Nov 2022 15:42:06 -0600 From: dana To: "Daniel Shahaf" , "Clinton Bunch" Cc: "Zsh hackers list" Subject: Re: [PATCH] zsh/random module [UPDATED] Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Seq: 51044 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Mon 7 Nov 2022, at 18:18, Clinton Bunch wrote: > '(-r)-L+[specify integer lower bound (implies -i)]: :_numbers -d$lmin = -l$lmin -m$max "integer lower bound"' \ > '(-r)-U+[specify integer upper bound (implies -i)]: :_numbers -d$umax = -l$umin -m$max "integer upper bound"' Was going to mention in my draft reply that the $max references here are broken now On Wed 23 Nov 2022, at 13:46, Daniel Shahaf wrote: > + Why should -c default to 8 in the "random bytes" case? Why > shouldn't it default to some other value, or even be required to be > specified explicitly by the user? ... > - Why should -c's default depend on anything at all? You mentioned > downthread you consider making -c1 the default in all cases; that'd = be > better. The defaults with this API are kind of weird, because if you make them dependent on the format (e.g. 8 for hex and 1 for everything else) it's = kind of arbitrary, but if you keep them all the same (e.g. 1 or 8 for everyth= ing) they aren't generally useful =E2=80=94 i think it's safe to assume that = 'i would like exactly 1 random hex digit' is not going to be the most common use case Requiring the user to explicitly specify it would address that, though y= ou could say then that it goes the other way, e.g. again it's probably safe= to assume that 90% of the time you're only going to want one integer value,= and making people write that out every time, whilst expected in a lower-leve= l API like a C function, is maybe annoying in a convenience shell built-in But annoying is probably better than confusing, if those are the options On Wed 23 Nov 2022, at 13:46, Daniel Shahaf wrote: >> +%test >> + getrandom -U 56 >> +1f:Checking if system has a kernel random source >> +?(eval):1: No kernel random pool found. >> + > > The test point's code has nothing to do with the test point's > description and expected errput. The assertion is backwards but i guess this is just testing to see if the module works on the system. But should that even be a test? Shouldn't th= ere instead be a %prep that just leaves the whole file unimplemented in this= case? Unless we're expecting the module to be both available and usable on eve= ry zsh build On Wed 23 Nov 2022, at 13:46, Daniel Shahaf wrote: > Oh, and bump that 16 to something 3 or 4 times as big, because a 1/655= 36 > chance isn't really enough in a world where automated builds (CI, > distros' QA, etc.) is a thing. I feel like it should be very nearly impossible for a test to fail just = for randomness reasons. Maybe it's over-kill but in my draft reply to the pa= tch i was going to suggest something like this: () { repeat $(( 10 ** 5 )); do getrandom -L4 -U5 -c64 -a tmpa [[ $tmpa[(r)5] =3D=3D 5 ]] && return 0 done return 1 } On Wed 23 Nov 2022, at 13:52, Daniel Shahaf wrote: > Could have something like this: > > "-f:specify format:(raw hex decimal)" I kind of like that On Wed 23 Nov 2022, at 14:33, Daniel Shahaf wrote: > 4. Which approach generalizes better? If we were to directly expose an underlying C API as in Matthew's propos= ed arc4random_uniform(), i think it would make sense to remain consistent w= ith that API. But in any other case i would prefer inclusive, and i think th= at fits nicely with other things in zsh as you said dana