WebAssembly Module

[Yongbeom-Kim]

Description

Webassembly module for SA

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Tested in separate repo, here

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[RichDom2185]

Hi! Just a minor comment, thanks for the hard work, looks good!

[RichDom2185]

Could you change the line-encoding of this file to CRLF instead of LF, in order to match the rest of the codebase?

It's a bit weird, but this repository uses CRLF encoding for files, even on Unix systems.

To change the line encoding, open the file on VSCode, the on the bottom right toolbar:

Click "Select End of Line Sequence" and change it to CRLF, then commit the changes.

[Yongbeom-Kim]

Thanks for the review!

I've changed the relevant settings on VS Code and fixed all eslint issues, which should have fixed the problem? I'm not entirely sure if the problem is gone, but eslint isn't giving me any warnings so I take it that the issue is fixed.

Please let me know if there's anything else (or if the issue persists)!

[tituschewxj]

I don't think the line-encoding is updated in the GitHub repository, it is only updated on your local files. You can check if there are warnings by refering to the GitHub Checks.

I think your git config core.autocrlf is set to true, so git will replace CRLF with the line encoding in the GitHub repository automatically, which is LF. Which is why it is not updated on the GitHub repository, even if you change it locally.

I faced a similar problem with the line-encodings, but I was able to fix it by referring to this: https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf

[leeyi45]

At some point someone configured the repository to use CRLF instead of LF (I believe it was @Cloud7050) within the eslint configuration, I've since left that as is. If we want to move back to LF it would be some minor changes to the build system

[Cloud7050]

Using git ls-files --eol, this repo appears to sometimes use LF and sometimes use CRLF in the index (and some files are even mixed). For comparison, the main js-slang repo appears to mainly use LF.

This repo's base eslint config is based on a config I've been carrying with me for a while. As I'm on Windows, that rule's setting is less of a concious choice for this repo. If I'm understanding this correctly, maybe it'll be better to:

• Rely on each user's git core.autocrlf config to handle line endings across platforms (true on Windows, input on Linux/macOS?)
• Turn off the linebreak-style rule in the base eslint config. Users are free to locally checkout LF or CRLF
• Push a commit that converts all existing files to be indexed with LF (could use something like eol-converter-cli on npm)

From there I think the repo may sometimes get CRLF introduced, but they would sometimes get corrected to LF down the line. Any thoughts?

[Yongbeom-Kim]

Thanks for the help with the line-encoding issue - I've fixed the issue with this PR, let me move this discussion to a fresh issue. #209

[martin-henz]

Is this PR ready to be merged? @Yongbeom-Kim

[RichDom2185]

I think we can merge this module in. @Yongbeom-Kim could you kindly resolve the conflicts? Thanks!

[Yongbeom-Kim]

Sorry for the late follow-up on this, PR is ready to be merged!

[RichDom2185]

LGTM, thanks!