From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D18EA25405 for ; Fri, 13 Sep 2019 18:28:44 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_lAdMIADZJP for ; Fri, 13 Sep 2019 18:28:44 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 13AA6251BD for ; Fri, 13 Sep 2019 18:28:40 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v2 1/4] app: serializers update now is reflected in Lua References: <20190912232254.twdmkuiz23gicmp2@tkn_work_nb> From: Vladislav Shpilevoy Message-ID: <1777a651-fd19-71d4-1c38-ef712b102eb7@tarantool.org> Date: Sat, 14 Sep 2019 00:32:30 +0200 MIME-Version: 1.0 In-Reply-To: <20190912232254.twdmkuiz23gicmp2@tkn_work_nb> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Alexander Turenko Cc: tarantool-patches@freelists.org Thanks for the review! On 13/09/2019 01:22, Alexander Turenko wrote: > LGTM. > > Small comments are below. > > WBR, Alexander Turenko. > >> src/lua/utils.c | 34 +++++++++++++++------------- >> test/app-tap/json.test.lua | 3 ++- >> test/app-tap/lua/serializer_test.lua | 13 +++++++++++ >> test/app-tap/msgpack.test.lua | 3 ++- > > It looks that it worth to add the test to test/app-tap/yaml.test.lua > too. The test is called 'test_depth' and YAML serializer does not check max depth. This is why I omitted it for YAML, deliberately. Next commits add here more depth-specific tests, and they will fail for YAML. >> 4 files changed, 35 insertions(+), 18 deletions(-) >> >> diff --git a/src/lua/utils.c b/src/lua/utils.c >> index 75efe0ed2..a082a2e5b 100644 >> --- a/src/lua/utils.c >> +++ b/src/lua/utils.c >> @@ -270,10 +270,8 @@ luaL_serializer_parse_option(struct lua_State *L, int i, >> struct luaL_serializer *cfg) > > Now the function pushes a value to a Lua stack, I think it worth to > update the doxygen-style comment. > I thought it is quite obvious, and the old comment was still valid. But ok: diff --git a/src/lua/utils.c b/src/lua/utils.c index a082a2e5b..6789a8477 100644 --- a/src/lua/utils.c +++ b/src/lua/utils.c @@ -258,7 +258,8 @@ luaL_serializer_create(struct luaL_serializer *cfg) } /** - * Configure one field in @a cfg. + * Configure one field in @a cfg. Value of the field is kept on + * Lua stack after this function, and should be popped manually. * @param L Lua stack. * @param i Index of option in OPTIONS[]. * @param cfg Serializer to inherit configuration. (I didn't describe it in @retval, because this C function does not return Lua values. It still returns the same - int pointer). >> /** >> - * @brief serializer.cfg{} Lua binding for serializers. >> - * serializer.cfg is a table that contains current configuration values from >> - * luaL_serializer structure. serializer.cfg has overriden __call() method >> - * to change configuration keys in internal userdata (like box.cfg{}). >> - * Please note that direct change in serializer.cfg.key will not affect >> - * internal state of userdata. > > The note is still actual, I would not remove it. The old comment is super overcomplicated and obvious I think. But ok: diff --git a/src/lua/utils.c b/src/lua/utils.c index 6789a8477..93e00d81f 100644 --- a/src/lua/utils.c +++ b/src/lua/utils.c @@ -302,9 +302,15 @@ luaL_serializer_parse_options(struct lua_State *L, } /** - * Serializer.cfg.__call implementation. Merge new parameters into - * both C structure of the serializer, and into its Lua table - * representation: serializer.cfg. + * @brief serializer.cfg{} Lua binding for serializers. + * serializer.cfg is a table that contains current configuration values from + * luaL_serializer structure. serializer.cfg has overriden __call() method + * to change configuration keys in internal userdata (like box.cfg{}). + * Please note that direct change in serializer.cfg.key will not affect + * internal state of userdata. Changes via cfg() are reflected in + * both Lua cfg table, and C serializer structure. + * @param L lua stack + * @return 0 */ static int luaL_serializer_cfg(struct lua_State *L) > > ( Sooner or later we should just do > https://github.com/tarantool/tarantool/issues/2867 ) > > Side note: I think that it is better to have one source of information > and have only a handle in Lua. Or maybe (if option(s) access cost is > matter) update the Lua table using some kind of triggers: if we'll > change an option from C, then the current implementation will fail to > track it. We could copy luaL_serializer to ffi.cdef so as Lua would be able to work with that structure directly. That looks like a piece of cake. > > Anyway, it is not a part of your issue. Just side thoughts. >