Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] RFC: OENTRY refactor

Another thing to think about is what information we get from parsing
UDOs that we store in OPCODINFO. There may be some things that we could
move to OENTRY (perhaps with different data structure design) as something
all opcodes have.

On Wed, Jan 3, 2024 at 10:34 PM Steven Yi <[email protected]> wrote:

> Now is certainly the time to add/subtract/modify things. What metadata are
> you thinking of? We can tell if an opcode acts just at init-time now by
> looking to see if it only has an iopadr (or initFunc as proposed) and no
> kopadr/aopadr (or perfFunc), then report that. Or am I missing something
> for that example?
>
> I suppose a good way we could work through this is to have some kind of
> example error message for a given code example then go implement it.
>
> On Wed, Jan 3, 2024 at 10:10 PM Eduardo Moguillansky <
> [email protected]> wrote:
>
>> If a refactor of OENTRY is in the works, could there be some discussion
>> to include some metadata about a given opcode, in order to make reflection
>> or error messages clearer? For example, at the moment there is no way to
>> tell if a given opcode acts at init time or only needs some initialization.
>> This information could be added
>>
>> On Wed, Jan 3, 2024, 20:51 Victor Lazzarini <[email protected]>
>> wrote:
>>
>>> Sounds good to me. It’s quite a big change though we’ll need make
>>> throughout the code to replace all the OENTRY etc
>>> (we’ll also have to think about the plugins in the plugins repo and
>>> update those for this).
>>>
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> > On 3 Jan 2024, at 22:42, Steven Yi <[email protected]> wrote:
>>> >
>>> > *Warning*
>>> > This email originated from outside of Maynooth University's Mail
>>> System. Do not reply, click links or open attachments unless you recognise
>>> the sender and know the content is safe.
>>> > Hi All,
>>> >
>>> > I was looking at OENTRY and think we can make a change to simplify it
>>> by:
>>> >
>>> > 1. Remove .thread
>>> > 2. Remove .aopadr
>>> > 3. Rename .iopadr to initFunc
>>> > 4. Rename .kopadr to perfFunc
>>> >
>>> > There's little code to check ->thread and I think it can be refactored
>>> to check the presence of initFunc or perfFunc. I think initFunc and
>>> perfFunc might be a little easier to understand for modern devs vs. iopadr
>>> and kopadr.
>>> >
>>> > Thoughts?
>>> >
>>> > Steven
>>>
>>>