From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id B595B469719 for ; Thu, 20 Feb 2020 23:53:40 +0300 (MSK) Date: Thu, 20 Feb 2020 23:48:20 +0300 From: Igor Munkin Message-ID: <20200220204820.GF404@tarantool.org> References: <6b8602a297876492179b695f317e809bd425af79.1582209853.git.imun@tarantool.org> <20200220180341.GA31973@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200220180341.GA31973@atlas> Subject: Re: [Tarantool-patches] [PATCH] build: disable LUAJIT_ENABLE_PAIRSMM List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy Kostja, On 20.02.20, Konstantin Osipov wrote: > * Igor Munkin [20/02/20 18:27]: > > This is pathetic. Don't you realize that once a version is > released and declared stable, it's a legacy you have to live with? As we announced the patch was applied by mistake. If you found the place we missed, please show it. If you want to complain and blame someone, feel free to choose me, since I initially proposed this amiss and breaking solution in #4560[1]. Unfortunately this doesn't make the situation easier for both of us. The fact we applied the patch makes me sorry (but I'll try to omit emotions from the ml). Moreover, such breakage can't be introduced within a minor release. Originally it was needed to implement the PoC for #4521[2] and wasn't considered as a feature per se. It formally breaks the semantics of the language currently being used for out platform. As we can see it really breaks the existing code. > > Now you have *3* broken behaviours to support, instead of just > two. Some people will still use a version which they believe is > stable, and encounter strange failures. I'm bad in math here, since I see only two behaviours: the old one and the broken one. Three would be if we settle the issue and save the introduced behaviour the way you proposed below. Then there will be: * working Tarantool w/o __pairs * broken Tarantool w/ __pairs * working Tarantool w/ __pairs But again: I might miscount it, so it would be great if you clarify your math. Yes, there are stable releases poisoned with the introduced breakage. If you think I'm careless about it, you're wrong. I guess we can ask users to upgrade like many times you used to say "obnovites" with apoligies. I wish we could avoid it this time. But I see more problems with the platform infrastructure and environment as a result than "blacklisting" several Tarantool versions. > > Eventually you'll have to enable 5.2 compatibility anyway (are you > going to stay with 5.1 forever??), and then break it again. I can't answer it now. You are the visionary, I'm even not a mainainer. We discussed it in tg chat some time ago but I haven't been answered the question about your vision of this question. I welcome you to proceed the discussion and you can choose the most convenient way for it. > > luafun is a builtin and table.deepcopy are builtins. What prevented you from fixing them > instead? > That would fix 99% of cases. I see no guarantees here, and guess you can provide nothing. > > > -- > Konstantin Osipov, Moscow, Russia [1]: https://github.com/tarantool/tarantool/issues/4560 [2]: https://github.com/tarantool/tarantool/issues/4521 -- Best regards, IM