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 44B4C2E925 for ; Fri, 21 Jun 2019 08:41:34 -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 6EZQ4iaWyK7U for ; Fri, 21 Jun 2019 08:41:34 -0400 (EDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id D33C62952A for ; Fri, 21 Jun 2019 08:41:33 -0400 (EDT) Received: by mail-lf1-f48.google.com with SMTP id y17so5004820lfe.0 for ; Fri, 21 Jun 2019 05:41:33 -0700 (PDT) Date: Fri, 21 Jun 2019 15:41:30 +0300 From: Cyrill Gorcunov Subject: [tarantool-patches] Re: [RFC] box/lua/console: Add console.fmt module Message-ID: <20190621124130.GB24106@uranus> References: <20190620215405.9338-1-gorcunov@gmail.com> <20190621073241.GJ18958@atlas> <20190621081640.GB18551@uranus> <20190621121412.GB5998@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190621121412.GB5998@atlas> 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: Konstantin Osipov Cc: tarantool-patches@freelists.org, Alexander Turenko On Fri, Jun 21, 2019 at 03:14:12PM +0300, Konstantin Osipov wrote: > > I don't care much about the internals here, but about the > consistency of the console api: > https://www.tarantool.io/en/doc/1.10/reference/reference_lua/console/ Well, I don't mind extending console api instead just need to figure out how to put the engine into separate file (serisouly, console.lua is already big enough). > > I don't see why we can't fork serpent. But OK, provided you don't > want serpent, what can serpent do that we're going to miss in an > own implementation? Could you write down a summary so that we can > analyze this ahead of time? I will write the summary, but most important part is that they are fetching dependency and code bloats like hell even if we don't need most of the parts of serpent/pretty-print (initially I started with serpent, integrated it into our code but didn't like the results much, then I merged pretty-print engine, and again found that we need own extensions for symbols like box.NULL which lead me to the conclusion that if we can't use vanilla code then there is no much point to carry these projects in our repo, better to stick small and simple functions and extend them with time if we have to).