Re: [Tarantool-patches] [PATCH luajit 2/3] dbg: introduce lj-ctype command, extend cdata dump

[Evgeniy Temirgaleev via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]

Sergey, thanks for the answer!

> I'm not sure that ctype_preplit -> dump_ctype_preplit helps for find the
> original logic for this dumper from the LuaJIT source code. So, I'm open
> to ideas ;).

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 :)

I can’t find cdata_val_int64 or cdata_val_complex in LuaJIT code, ‘dump_’ prefix missed?

--
Best regards,
Evgeniy Temirgaleev

> 
> From: Sergey Kaplun <skaplun@tarantool.org>
> To: Evgeniy Temirgaleev <e.temirgaleev@tarantool.org>
> Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov <sergeyb@tarantool.org
> >
> Date: Tuesday, June 30, 2026 3:27 PM +03:00
> Evgeniy,
> Thanks for the answer, see my thoughts below.
> 
> On 30.06.26, Evgeniy Temirgaleev wrote:
> > Hi, Sergey!
> >
> > LGTM. And please see my note about renaming issue.
> >
> > >
> > > From: Sergey Kaplun <skaplun@tarantool.org>
> > > To: Evgeniy Temirgaleev <e.temirgaleev@tarantool.org>
> > > Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov <sergeyb@tarantool.org
> 
> > > >
> > > Date: Monday, June 29, 2026 10:21 PM +03:00
> 
> <snipped>
> 
> > > > > +
> > > > > +def ctype_isrefarray(info):
> > > > > + return (info & (CTMASK_NUM | CTF_VECTOR | CTF_COMPLEX)) == \
> > > > > + ctinfo(CT_ARRAY, 0)
> > > > > +
> > > > > +
> > > > > +def ctype_cid(info):
> > > > >
> > > >
> > > > Let’s put these function definitions in the ‘lj_ctype.h’ order?
> > > > May we group the definitions by corresponding C files also? #
> lj_ctype.h
> > > … # lj_cdata.h … # lj_xxx.c …
> > >
> > >
> > > Sorted as you suggested. The sorting is the following:
> > > * lj_ctype.h
> > > * lj_cdata.h -- `cdata_getptr()`
> > > * lj_obj.h -- `cdataptr()`
> > >
> >
> > Thanks! We can add a comment with file name before each block to improve
> readability slightly more. Feel free to ignore.
> 
> I suppose that ctags or whatsoever will do the trick. Ignoring since you
> don't insist.
> 
> <snipped>
> 
> > > > >
> > > >
> > > > Also, it seems, it will be easy to read to code, if it will be
> possible
> > > to distinguish between ported functions and extension itself ones. May
> be
> > > by use the ‘dbg_’ prefix for extension function names.
> > >
> > > I suppose this refactoring can be done in the separate issue. Since it
> 
> > > is related to all functions. Also, the `dbg` is already used for the
> > > instance of the corresponding class. `dump_` prefix looks common for
> all
> > > dumpers of our extension.
> > >
> >
> > Agreed. And I vote for this patch.
> > 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`.
> > 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?
> 
> For now we have several "prefixes":
> * `dbg.` for the debugger implementation defined helpers.
> * `dump_` for the dumper function of any kind (even helpers).
> * `LJ*` for the classes to be the entry points for our extensions.
> 
> I'm not sure that ctype_preplit -> dump_ctype_preplit helps for find the
> original logic for this dumper from the LuaJIT source code. So, I'm open
> to ideas ;).
> 
> I prefer if the refactoring of names will be done separately so there
> is no a part of the naming in this patch series and another part in the
> next one. At least this is inconsistent.
> 
> <snipped>
> 
> >
> > --
> > Best regards,
> > Evgeniy Temirgaleev
> 
> --
> Best regards,
> Sergey Kaplun
>

[-- Attachment #2: Type: text/html, Size: 5273 bytes --]