From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Alexander Turenko <alexander.turenko@tarantool.org> Cc: tarantool-patches@freelists.org Subject: Re: [PATCH v2 2/6] Add functions to ease using Lua iterators from C Date: Wed, 16 Jan 2019 15:20:38 +0300 [thread overview] Message-ID: <20190116122038.udcbj4qbb5gung2c@esperanza> (raw) In-Reply-To: <20190116114012.gxw4q3nxj7moopx6@tkn_work_nb> On Wed, Jan 16, 2019 at 02:40:12PM +0300, Alexander Turenko wrote: > > > > > + > > > > > +/** > > > > > + * Create a Lua iterator from {gen, param, state}. > > > > > > > > May be, we could pass idx == 0 to create an iterator from > > > > gen, param, state (without a table)? Would it be worthwhile? > > > > > > > > > > I think it is good idea, because cases could be different. My thought > > > was that we'll add another function for this case (if we'll need), but > > > using idx == 0 is better. I created the similar API before for > > > luaT_newtuple(). > > > > > > And I think the new merger API will require it. > > > > The patch looks good to me now, but I'm still not sure the new merger > > implementation will need to deal with Lua iterators in C at all, as one > > can easily write a wrapper function in Lua turning an iterator to a > > 'fetch' closure, which then can be passed to a source constructor. > > This is not the thread about merger, but the idea looks weird for me. > 'next' has one meaning (get one tuple), 'fetch' has another meaning (get > next tuples batch). 'next' is written in C and predefined, 'fetch' is > user-defined Lua function. When you'll try to express one over another > you'll find rough edges, e. g. need of extra wrapping table. Yep, why not wrap an iterator/table/whatever so that it works as fetch() closure taken by one of available source constructors. > > But my main objection is that it is hard to think what is going on > when 'next' and 'fetch' are mixed. I never mixed those. 'next' would be a C function returning C tuples. This would be a method of a source. It would be used by a merger to get the next tuple to merge. It would also be used by source:pairs() Lua function. 'fetch' would be a Lua function returning either Lua tuples or tuple batches (represented by Lua tables or raw msgpack). What exactly it returns depends on the source type.
next prev parent reply other threads:[~2019-01-16 12:20 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-09 20:20 [PATCH v2 0/6] Merger Alexander Turenko 2019-01-09 20:20 ` [PATCH v2 1/6] Add luaL_iscallable with support of cdata metatype Alexander Turenko 2019-01-10 12:21 ` Vladimir Davydov 2019-01-09 20:20 ` [PATCH v2 2/6] Add functions to ease using Lua iterators from C Alexander Turenko 2019-01-10 12:29 ` Vladimir Davydov 2019-01-15 23:26 ` Alexander Turenko 2019-01-16 8:18 ` Vladimir Davydov 2019-01-16 11:40 ` Alexander Turenko 2019-01-16 12:20 ` Vladimir Davydov [this message] 2019-01-17 1:20 ` Alexander Turenko 2019-01-28 18:17 ` Alexander Turenko 2019-03-01 4:04 ` Alexander Turenko 2019-01-09 20:20 ` [PATCH v2 3/6] lua: add luaT_newtuple() Alexander Turenko 2019-01-10 12:44 ` Vladimir Davydov 2019-01-18 21:58 ` Alexander Turenko 2019-01-23 16:12 ` Vladimir Davydov 2019-01-28 16:51 ` Alexander Turenko 2019-03-01 4:08 ` Alexander Turenko 2019-01-09 20:20 ` [PATCH v2 4/6] lua: add luaT_new_key_def() Alexander Turenko 2019-01-10 13:07 ` Vladimir Davydov 2019-01-29 18:52 ` Alexander Turenko 2019-01-30 10:58 ` Alexander Turenko 2019-03-01 4:10 ` Alexander Turenko 2019-01-09 20:20 ` [PATCH v2 5/6] net.box: add helpers to decode msgpack headers Alexander Turenko 2019-01-10 17:29 ` Vladimir Davydov 2019-02-01 15:11 ` Alexander Turenko 2019-03-05 12:00 ` Alexander Turenko 2019-01-09 20:20 ` [PATCH v2 6/6] Add merger for tuple streams Alexander Turenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190116122038.udcbj4qbb5gung2c@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=alexander.turenko@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [PATCH v2 2/6] Add functions to ease using Lua iterators from C' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox