From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 680271B6BE7D; Wed, 18 Mar 2026 17:41:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 680271B6BE7D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1773844865; bh=q76HRPHelqet0NLWWr+HGjDJrasKiNaFjfkCfJ3F0iE=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=pEIVgAZTZha70Q+SYdLo/eRlJv1X6s9SzBMlEZvRxw94KHN7GJFHaA99heFI+oNvt 52T6ujkzWaQqRD7z9/LBtj+5FF36w5QW3joNMz3EN2kHw4x4hjXISpsKqLN+mGU+S1 s5487Jv8L8OLq7/yWRp8r7RkUQ/RaLp5whQlGCP0= Received: from send175.i.mail.ru (send175.i.mail.ru [95.163.59.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 63F701B6BE7B for ; Wed, 18 Mar 2026 17:41:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 63F701B6BE7B Received: by exim-smtp-57656fb979-pbtx9 with esmtpa (envelope-from ) id 1w2s51-00000000Gfp-13Cm; Wed, 18 Mar 2026 17:41:03 +0300 Date: Wed, 18 Mar 2026 17:42:01 +0300 To: Sergey Bronnikov Cc: Sergey Bronnikov , tarantool-patches@dev.tarantool.org Message-ID: References: <7f14d93b-f295-434f-898c-3409daee3053@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9A2BFDE4DD2630CDA58E3A656E0B0F0056A0DCC6CA80B3313182A05F5380850400A846B16A7B986863DE06ABAFEAF67057EAE5AAF0D1D200BCC8B5E2407204550A7427CD01E6BCEC9 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7AC4684DF4EC4B256EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AC83A81C8FD4AD23D82A6BABE6F325AC2E85FA5F3EDFCBAA7353EFBB55337566BCD8AD057D84402C111AAE9B0F442618F09AF4B343559AE7A1260C7BABA33C23389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C04CF195F1528592878941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B65FF0BFC5AEE34BE6CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C2249F3DD27CEE54E359176E601842F6C81A12EF20D2F80756B5FB606B96278B59C4276E601842F6C81A127C277FBC8AE2E8BCFA9DE07C563E1613AA81AA40904B5D99C9F4D5AE37F343AD1F44FA8B9022EA23BBE47FD9DD3FB595F5C1EE8F4F765FC72CEEB2601E22B093A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E73557739F23D657EF2BB5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5208528D220231BE95002B1117B3ED6962CB399C597A72A6733EE06AFCD964888823CB91A9FED034534781492E4B8EEAD0D89974173551D4FBDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0AD73CAD6646DEDE1918E10F71CB4DF9F96AB70F9BE574AE9C625B6776AC983F447FC0B9F89525902EE6F57B2FD27647F25E66C117BDB76D6596EEF773C3F3436FE6694FC4FF999CD4F7CE31E8069DD7208B34813CB8C05C5EC3273DA5A93A270B5B8341EE9D5BE9A0ABF6D2902B755A7AB6877C9C183AFC533290B25C1070A7E426536EB022892E5344C41F94D744909CECFA6C6B0C050A61A8CAF69B82BA93681CD72808BE417F3B9E0E7457915DAA85F X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXMZebaIdHP2ghjoIc/363UZI6Kf1ptIMVdbVVJCphTR/XAk3QF9xbRI= X-Mailru-Sender: 520A125C2F17F0B17094CDC02B85F11B0A0077FD6B664D683DE06ABAFEAF67057EAE5AAF0D1D200BB7CBEF92542CD7C88B0A2698F12F5C9EC77752E0C033A69E86920BD37369036789A8C6A0E60D2BB63A5DB60FBEB33A8A0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] misc: introduce flags with profiler support status X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey, Thanks for the fix! LGTM. > >>> Don't get the point here: > >>> 1) We will see this error much earlier in that case. > >>> 2) We will see with your approach as well. > >>> > >>> I don't get the reason for the `type()` call if the check below will > >>> fail with a different type as well (since Lua checks types first). I see > >>> no reason in double-checking that means nothing. > >> The same sense as with checking both boolean value for pcall and an > >> error message, see for example > >> > >> your patch in [1]: > >> > >> +test:ok(not result, 'correct status for recursive call') > >> +test:like(errmsg, 'stack overflow', 'correct error message for > >> recursive call') > >> > >> In aforementioned patch you can check only message, but you check both > >> values. > >> > >> 1. > >> https://lists.tarantool.org/tarantool-patches/20260316104853.23901-1-skaplun@tarantool.org/T/#u > > This is not quite the same, IMO. These checks test 2 __different__ > > returned values. 1 -- the status, 2 -- the error message. It is possible > > that the status is true, and there is no error message as well: > > > > | luajit -e 'print(pcall(error)); print(pcall(tonumber, "abc"))' > > | false nil > > | true nil > > > > So, if we get nil, we can distinguish these 2 cases. > > > > But from your point of view, the checks should look like the following: > > |test:ok(type(result) == 'boolean', 'correct status type') > > |test:ok(not result, 'correct status for recursive call') > > |test:ok(type(errmsg) == 'string', 'correct errmsg type') > > |test:like(errmsg, 'stack overflow', 'correct error message for recursive call') > > > > Note that in that case, if the type is incorrect, you should modify the > > test anyway to debug the behaviour (or inspect the test in the GDB). > > > > Side note: Anticipating your question: we don't check the type of the > > first returned value for the `pcall()` because it isn't the unit test > > for `pcall()`. Hence, we expect that it follows the behaviour declared > > in the Lua RefMan. > > It's possible that the value's type can change, and it won't be a > Boolean value, > > especially since we use a LJLIB_ machinery (imagine you change the "top-2" > > to the "top-3", for example). I want the test to catch this as early as > possible. > > It's fair to say that in tests, I have an extreme lack of trust to the > system under test, especially when a SUT is a LuaJIT. > > It's easier to parse the results of a failed test there. These checks > are cheap > > and only take one line, so I don't understand why we spend so much time > discussing this. I just want to understand your point of view. As I said before -- I don't insist on the changes. -- Best regards, Sergey Kaplun