

<HTML><BODY><div class="cl-5ul7s4pwte"><div>Sergey, thanks for the answer!</div><div> </div><div>> I'm not sure that ctype_preplit -> dump_ctype_preplit helps for find the<br>> original logic for this dumper from the LuaJIT source code. So, I'm open<br>> to ideas ;).<br> </div><div>I think, we can use original names from LuaJIT(ctype_prelit for ctype_prelit) and differ names for routines which are not present in LuaJIT. No more ideas at a time :)</div><div> </div><div>I can’t find cdata_val_int64 or cdata_val_complex in LuaJIT code, ‘dump_’ prefix missed?</div><div> </div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Best regards,</div><div>Evgeniy Temirgaleev</div></div></div><br><div class="mail-quote-collapse"><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px"><span>From: Sergey Kaplun <<a href="mailto:skaplun@tarantool.org">skaplun@tarantool.org</a>><br>To: Evgeniy Temirgaleev <<a href="mailto:e.temirgaleev@tarantool.org">e.temirgaleev@tarantool.org</a>><br>Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov <<a href="mailto:sergeyb@tarantool.org">sergeyb@tarantool.org</a>><br>Date: Tuesday, June 30, 2026 3:27 PM +03:00</span><br> <div><div id=""><div class="cl-2lm8b505bu"><div class="js-helper_mr_css_attr js-readmsg-msg_mr_css_attr"><div id="style_17828224771288591130_mr_css_attr"><div id="style_17828224771288591130_BODY_mr_css_attr">Evgeniy,<br>Thanks for the answer, see my thoughts below.<br><br>On 30.06.26, Evgeniy Temirgaleev wrote:<br>> Hi, Sergey!<br>><br>> LGTM. And please see my note about renaming issue.<br>><br>> ><br>> > From: Sergey Kaplun <<a href="mailto:skaplun@tarantool.org">skaplun@tarantool.org</a>><br>> > To: Evgeniy Temirgaleev <<a href="mailto:e.temirgaleev@tarantool.org">e.temirgaleev@tarantool.org</a>><br>> > Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov <<a href="mailto:sergeyb@tarantool.org">sergeyb@tarantool.org</a><br>> > ><br>> > Date: Monday, June 29, 2026 10:21 PM +03:00<br><br><snipped><br><br>> > > > +<br>> > > > +def ctype_isrefarray(info):<br>> > > > + return (info & (CTMASK_NUM | CTF_VECTOR | CTF_COMPLEX)) == \<br>> > > > + ctinfo(CT_ARRAY, 0)<br>> > > > +<br>> > > > +<br>> > > > +def ctype_cid(info):<br>> > > ><br>> > ><br>> > > Let’s put these function definitions in the ‘lj_ctype.h’ order?<br>> > > May we group the definitions by corresponding C files also? # lj_ctype.h<br>> > … # lj_cdata.h … # lj_xxx.c …<br>> ><br>> ><br>> > Sorted as you suggested. The sorting is the following:<br>> > * lj_ctype.h<br>> > * lj_cdata.h -- `cdata_getptr()`<br>> > * lj_obj.h -- `cdataptr()`<br>> ><br>><br>> Thanks! We can add a comment with file name before each block to improve readability slightly more. Feel free to ignore.<br><br>I suppose that ctags or whatsoever will do the trick. Ignoring since you<br>don't insist.<br><br><snipped><br><br>> > > ><br>> > ><br>> > > Also, it seems, it will be easy to read to code, if it will be possible<br>> > to distinguish between ported functions and extension itself ones. May be<br>> > by use the ‘dbg_’ prefix for extension function names.<br>> ><br>> > I suppose this refactoring can be done in the separate issue. Since it<br>> > is related to all functions. Also, the `dbg` is already used for the<br>> > instance of the corresponding class. `dump_` prefix looks common for all<br>> > dumpers of our extension.<br>> ><br>><br>> Agreed. And I vote for this patch.<br>> May be it will be several documented prefixes. It will be more verbosely, but I think it will be very helpful in a long perspective for supporting the extension to quick distinguish LuaJIT-ported routine e.g. `ctype_preplit` with extension routine e.g. `cdata_val_int64`.<br>> Can you offer some prefix name good for you now? May be we can start naming with it at this point, what do you think?<br><br>For now we have several "prefixes":<br>* `dbg.` for the debugger implementation defined helpers.<br>* `dump_` for the dumper function of any kind (even helpers).<br>* `LJ*` for the classes to be the entry points for our extensions.<br><br>I'm not sure that ctype_preplit -> dump_ctype_preplit helps for find the<br>original logic for this dumper from the LuaJIT source code. So, I'm open<br>to ideas ;).<br><br>I prefer if the refactoring of names will be done separately so there<br>is no a part of the naming in this patch series and another part in the<br>next one. At least this is inconsistent.<br><br><snipped><br><br>><br>> --<br>> Best regards,<br>> Evgeniy Temirgaleev<br><br>--<br>Best regards,<br>Sergey Kaplun</div></div></div></div></div></div></blockquote></div></div></BODY></HTML>