Skip to content

Conversation

@asilvas
Copy link
Contributor

@asilvas asilvas commented Oct 1, 2023

This PR also includes new patterns for:

  • Custom constructors that differ across indexes
  • Getters/Setters
  • Custom index props

describe('#constructor', () => {
it('1 arg will result in index with default neighbors & metric', () => {
const index = new IndexHNSW(2);
expect(index.getDimension()).toBe(2);
Copy link
Contributor Author

@asilvas asilvas Oct 1, 2023

Choose a reason for hiding this comment

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

Ideally we'd be able to check the value of neighbors & metrics, but indexes don't expose those props so I kept this way for consistency with faiss. This check is only useful to show it doesn't throw.

@asilvas
Copy link
Contributor Author

asilvas commented Oct 1, 2023

Not sure I understand the build failures as IndexHNSW doesn't seem defined in the bindings somehow. Works great locally.

Seems like it might be related to this command:

npm info run faiss-node@0.5.0 install node_modules/faiss-node prebuild-install --runtime napi --verbose || (npm i cmake-js && npm run build)

It doesn't appear to actually be building, and instead using an older build artifact. Might be related to other build failures too. This is confirmed if you look at the unit test jobs which do pass because they're invoking a build.

@ewfian
Copy link
Owner

ewfian commented Oct 2, 2023

Not sure I understand the build failures as IndexHNSW doesn't seem defined in the bindings somehow. Works great locally.

Seems like it might be related to this command:

npm info run faiss-node@0.5.0 install node_modules/faiss-node prebuild-install --runtime napi --verbose || (npm i cmake-js && npm run build)

It doesn't appear to actually be building, and instead using an older build artifact. Might be related to other build failures too. This is confirmed if you look at the unit test jobs which do pass because they're invoking a build.

Yes, these two pipelines do use old build. The purpose is to confirm that the packages to be released can be installed and imported correctly in various environments. I would move these two builds to run on release(on push tags) rather than in every PR. (See :4b57bc4)
And, I'm considering adding Window and Linux environments in Unit Test Pipelines

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