Skip to content

Conversation

@rvirding
Copy link
Owner

@rvirding rvirding commented Jun 21, 2025

Here we fix the handling of strings in the string module. It behaves as it should but the formatting of some numerical output strings, while it is correct, does not quite look the same as the Lua module. This is because the Lua implementation uses C libraries while Luerl uses Erlang libraries.

{Cr,St2} = var_rest(Rest, St1),
{dot(L, Ce, Cr),St2};
var({{'NAME',L,N},_Attrib}, St) ->
%% Fro now we ignore attributes.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
%% Fro now we ignore attributes.
%% For now we ignore attributes.

rvirding added 6 commits June 24, 2025 16:38
It is now correct and compatible.
Loading in a file should now result in bytes and not potential unicode
codepoints.
Now it is only done in the \u{...} where it should be.
They are now accepted in the syntax of local variables but the
compiler ignores them.
%s now checks for '0' in string when it should, though it handles
other options in the C fashion.
These are now more compatible with the standard Lua ones. It will have
to do until someone seriously requests more.
@rvirding
Copy link
Owner Author

rvirding commented Jul 7, 2025

Can leave luerl_comp_normalise.erl as it is because the next PR I add will fix parsing and do more in luerl_comp_normalise.erl

@rvirding
Copy link
Owner Author

rvirding commented Jul 7, 2025

OK, if we are happy with this I will merge it.

@rvirding rvirding merged commit 812a3cc into develop Jul 11, 2025
5 checks passed
@rvirding rvirding deleted the develop-compat branch August 4, 2025 14:02
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.

2 participants