[WIP] JS binding

[realtmxi]

Initialization for js binding.

• Use NodeJS C++ addons

[1a1a11a]

I assume this is WIP, let me if you need me to review and merge it.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[realtmxi]

I assume this is WIP, let me if you need me to review and merge it.

Hi, sorry about the delay. I add a JS binding for libCacheSim locally. You can follow the README to test it.

In addition, current binding requires local building from the source. After review, I could consider to make it being a published npm package.

[1a1a11a]

I am getting an error when installing

/usr/bin/ld: /proj/cache-PG0/jason/libCacheSim/libCacheSim-node/../_build/liblibCacheSim.a(BeladySize.c.o): relocation R_X86_64_TPOFF32 against `params_str.0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

[realtmxi]

I am getting an error when installing

/usr/bin/ld: /proj/cache-PG0/jason/libCacheSim/libCacheSim-node/../_build/liblibCacheSim.a(BeladySize.c.o): relocation R_X86_64_TPOFF32 against `params_str.0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Hi, I identified the cause of the error — it was due to missing the -fPIC compiler flag. I've added it, and the issue is now resolved on my side.

[1a1a11a]

Awesome work! Shall we add some instructions on how to install it globally? BTW, publishing as an npm package sounds good to me!

[realtmxi]

To publish as a public npm package, there are two solutions:

1. source code compilation: the npm package includes the source code of libCacheSim library. When a user runs npm install, the C++ source code is complied directly on their machine

• cons: slower installation; potential for compilatoni errors (since I cannot run the one-line install, cd scripts && bash install_dependency.sh && bash install_libcachesim.sh, I would meet some compilation error and have to mannually install the libCacheSim.
• pros: always up-to-date binaries

2. pre-compiled binaries (distributed with the package)
   like sqlite3 use this method.
   Pros: faster installation; no build tools required for users
   Cons: require maintenance and update binaries for all supported platforms with every new release

I prefer method 1, but what's your preference?

[realtmxi]

I updated. Now, it support the local global installation.

[1a1a11a]

I think approach 2 might be better, because we do not expect frequent updates. We could automate the publishing process as a GitHub action. The main issue with approach 1 is that 1. it can be tricky for JavaScript developers to figure out C compilation errors; and 2. if we introduce some incompatible changes, it may cause a cascading failure.

To publish as a public npm package, there are two solutions:

1. source code compilation: the npm package includes the source code of libCacheSim library. When a user runs npm install, the C++ source code is complied directly on their machine

• cons: slower installation; potential for compilatoni errors (since I cannot run the one-line install, cd scripts && bash install_dependency.sh && bash install_libcachesim.sh, I would meet some compilation error and have to mannually install the libCacheSim.
• pros: always up-to-date binaries

2. pre-compiled binaries (distributed with the package)
   like sqlite3 use this method.
   Pros: faster installation; no build tools required for users
   Cons: require maintenance and update binaries for all supported platforms with every new release

I prefer method 1, but what's your preference?

[realtmxi]

I think approach 2 might be better, because we do not expect frequent updates. We could automate the publishing process as a GitHub action. The main issue with approach 1 is that 1. it can be tricky for JavaScript developers to figure out C compilation errors; and 2. if we introduce some incompatible changes, it may cause a cascading failure.

To publish as a public npm package, there are two solutions:

1. source code compilation: the npm package includes the source code of libCacheSim library. When a user runs npm install, the C++ source code is complied directly on their machine

• cons: slower installation; potential for compilatoni errors (since I cannot run the one-line install, cd scripts && bash install_dependency.sh && bash install_libcachesim.sh, I would meet some compilation error and have to mannually install the libCacheSim.
• pros: always up-to-date binaries

2. pre-compiled binaries (distributed with the package)
   like sqlite3 use this method.
   Pros: faster installation; no build tools required for users
   Cons: require maintenance and update binaries for all supported platforms with every new release

I prefer method 1, but what's your preference?

Hi, to make these easier to review, I expect to merge this PR to focus on one goal: enabling js binding building from source.
I plan to submit a new PR to introduce the pre-compiled binaries and a Github Actions workflow for automated publishing in a new branch later.
I believe this two-step approach breaks the changes into smaller, manageable steps. Let me know what you think, looking forward to hearing from you!
Best
-- Murphy

[cursor]

🚨 BugBot couldn't run

Pull requests from forked repositories are not yet supported (requestId: serverGenReqId_f0fe78a1-0978-4434-bdad-f4a2d5a79bb7).

[1a1a11a]

Sounds good to me!

[sonarqubecloud]

Quality Gate failed

Failed conditions
12.3% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud