Skip to content

[Refactor] Streamline error message creation#4593

Merged
Kebap merged 26 commits intodevelopmentfrom
streamline_error_messages
Jan 8, 2021
Merged

[Refactor] Streamline error message creation#4593
Kebap merged 26 commits intodevelopmentfrom
streamline_error_messages

Conversation

@Kebap
Copy link
Copy Markdown
Contributor

@Kebap Kebap commented Jan 7, 2021

Brief overview of PR changes/additions

Use dedicated functions to verify lua argument types given by users

Motivation for adding to Mudlet

Less repetition, more standardisation, easier readability and writability

Other info (issues closed, discussion etc)

Helpful tool to tackle a probably large part of #2091

Current draft as proof of concept can be tested with createMapLabel()
https://wiki.mudlet.org/w/Manual:Lua_Functions#createMapLabel

labelID = createMapLabel(areaID, text, posx, posy, posz, fgRed, fgGreen, fgBlue, bgRed, bgGreen, bgBlue, zoom, fontSize, showOnTop, noScaling)

edit: All arguments of this function's have been ported to new style messages.

The following arguments have been ported to new style messages for testing of many possible style combinations:

  • areaID - integer
  • text - string
  • posX - float
  • zoom - optional float
  • showOnTop - optional boolean

Try giving wrong argument types to any of these (and the non-listed unchanged ones) and see what happens.

@add-deployment-links
Copy link
Copy Markdown

add-deployment-links bot commented Jan 7, 2021

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

@Kebap
Copy link
Copy Markdown
Contributor Author

Kebap commented Jan 7, 2021

May need to refactor into macro, because the function should return the object, but may also return int upon failure.

// The "isOptional" parameter is optional, and will default to not-optional parameters! :)
//
// See also: verifyString, verifyInt, verifyFloat, announceWrongArgumentType
bool TLuaInterpreter::verifyBoolean(lua_State* L, const int pos, const QString& functionName, const QString& publicName, const bool isOptional)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the strings are squirted straight into a lua_pushfstring(...) you do not need to dress them up as QStrings - const char* is perfectly fine in this particular circumstances...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might help with all those errors further down! 😜

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which errors are you referring? Is this wrong or merely inconvenient?
I for one know QString better than char* so I used what I knew already.

Copy link
Copy Markdown
Member

@SlySven SlySven Jan 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cannot pass object of non-trivial type 'const QString' through variadic function; call will abort at runtime [-Wnon-pod-varargs]

You cannot use a QString as a parameter to go into a %s in a lua_pushfstring(...) call, you need to convert it back to a const char* with a QString::toUft8() followed by a QByteArray::constData() call - so you might just as well avoid a round trip from const char* ==> QString ==> const char* ...

{
if (!lua_isstring(L, pos)) {
announceWrongArgumentType(L, pos, functionName, publicName, "string", isOptional);
return lua_error(L);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess you just have to use:

    lua_error(L);
    Q_UNREACHABLE();
    return {};

here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion!

@Kebap
Copy link
Copy Markdown
Contributor Author

Kebap commented Jan 7, 2021

Try giving wrong argument types to any of these (and the non-listed unchanged ones) and see what happens.

This seems to work now:

image

@Kebap Kebap marked this pull request as ready for review January 7, 2021 22:18
@Kebap Kebap requested a review from a team as a code owner January 7, 2021 22:18
@Kebap Kebap requested review from a team January 7, 2021 22:18
Copy link
Copy Markdown
Member

@vadi2 vadi2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it looks good! I'd rename the verify suffix to something else, since the primary purpose is not to verify, but to retrieve the data value. Verification is the secondary purpose.

Will you be removing the old code / doing up the rest of the function?

@Kebap
Copy link
Copy Markdown
Contributor Author

Kebap commented Jan 8, 2021

I actually found verify a short and exact description of what happened, but am open to suggestions. Maybe getVerifiedString instead?

I will complete createMapLabel and remove comments as part of this PR. The other functions are part of the linked issue instead.

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jan 8, 2021

To me verify just means that, verify. I was confused as to where the actual data retrieval comes in then. getVerifiedString sounds good 👍

@Kebap
Copy link
Copy Markdown
Contributor Author

Kebap commented Jan 8, 2021

Motivation for adding to Mudlet

Less repetition, more standardisation, easier readability and writability

I like this, less clutter, less noise, more to the point information:

diff

The original had double size still, cut for brevity

Copy link
Copy Markdown
Member

@vadi2 vadi2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this improvement the API would be like "static argument, dynamic argument, static argument, dynamic argument" - making it a bit of a pain to copy/paste around - might be worthwhile to change it to "static argument, static argument, dynamic argument, dynamic argument"

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jan 8, 2021

#4593 (comment) yeah, great improvement for sure!

@Kebap
Copy link
Copy Markdown
Contributor Author

Kebap commented Jan 8, 2021

With this improvement the API would be like "static argument, dynamic argument, static argument, dynamic argument" - making it a bit of a pain to copy/paste around - might be worthwhile to change it to "static argument, static argument, dynamic argument, dynamic argument"

I actually had it like that before:
posZ = getVerifiedFloat(L, "createMapLabel", 5, "posZ");
But then changed it to this:
posZ = getVerifiedFloat(L, 5, "createMapLabel", "posZ");
Because we already use a lot of these:
posZ = lua_tonumber(L, 5);
And they seem easier to migrate this way.

You argument holds merit, too. Not sure which is worse.. 🤔

edit: Let's try it out again!

Kebap and others added 2 commits January 8, 2021 09:57
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Jan 8, 2021

Very nice solution to something we've been stuck on for a long while!

@Kebap Kebap added this to the 5.0 beginner-friendly milestone Jan 8, 2021
@Kebap Kebap merged commit 48f9727 into development Jan 8, 2021
@Kebap Kebap deleted the streamline_error_messages branch January 8, 2021 10:36
@Kebap Kebap mentioned this pull request Jan 15, 2021
Chris7 pushed a commit to Chris7/Mudlet that referenced this pull request Jan 2, 2022
Co-authored-by: Vadim Peretokin <vperetokin@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants